[Bug translation/94698] Improper French translation for "override"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94698 --- Comment #4 from Frederic Marchal --- French translation has been updated and submitted to the Translation Project. Thanks for the report.
[Bug c/93910] -Waddress-of-packed-member triggered without actual access to a member or the address of a member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93910 --- Comment #8 from Frederic Marchal --- Regarding the pointer vs pointeur typo in French, it will be fixed with the next translation update. Thanks for reporting it.
[Bug translation/80055] do not mark internal compiler error messages for i18n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80055 --- Comment #8 from Frederic Marchal --- Two years later, I appear to be the only active translator. I translated all the messages. So, cutting down the number of messages is not an issue I feel overly concerned with :-) Removing the internal error translations means more work for you. Will it benefit gcc and attract more translators? I doubt it. 13k messages is pretty daunting. Shortening it by several hundred messages will not help much. You can certainly spend your time on a more productive task. Unless fellow translators show up and challenge my opinion, I believe you can close this bug or postpone it. As the one doing the job, the decision is entirely up to you :-)
[Bug fortran/84354] Replace '%qs' with %qs in fortran/decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84354 --- Comment #2 from Frederic Marchal --- You are right. Only three occurrences of '%qs'. It looked like more when I translated those messages :-)
[Bug fortran/84354] New: Replace '%qs' with %qs in fortran/decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84354 Bug ID: 84354 Summary: Replace '%qs' with %qs in fortran/decl.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- Many occurrence of '%qs' in fortran/decl.c. %qs is already quoted. '%qs' is doubly quoted.
[Bug translation/84303] New: Styled quotes in error message may be inappropriate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84303
Bug ID: 84303
Summary: Styled quotes in error message may be inappropriate
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: fmarchal at perso dot be
Target Milestone: ---
In config/rs6000/rs6000.c, one can find the following code:
if (error_p)
{
const char *eprefix, *esuffix;
ret = false;
if (attr_p)
{
eprefix = "__attribute__((__target__(";
esuffix = ")))";
}
else
{
eprefix = "#pragma GCC target ";
esuffix = "";
}
if (cpu_opt)
error ("invalid cpu %qs for %s%qs%s", cpu_opt, eprefix,
q, esuffix);
else if (not_valid_p)
error ("%s%qs%s is not allowed", eprefix, q, esuffix);
else
error ("%s%qs%s is invalid", eprefix, q, esuffix);
}
}
The "%s%qs%s" part used to be "%s\"%s\"%s". I think the old syntax was better
because it matches what the source code looks like. %qs is equivalent to « %s »
in French.
[Bug translation/84207] New: Hard coded plural in gimple-fold.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84207 Bug ID: 84207 Summary: Hard coded plural in gimple-fold.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- In gimple-fold.c, size_one_node is used to build a hard coded plural rule such as in https://github.com/gcc-mirror/gcc/blob/de590a611e701935c4b3a73e78ec69c2bdfa58a1/gcc/gimple-fold.c#L1698 The rule to pluralize a word must be left to the translator.
[Bug target/79868] aarch64: diagnostic "malformed target %s value" not translateable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79868
--- Comment #7 from Frederic Marchal ---
I think there is an error here:
@@ -9938,7 +9978,7 @@ aarch64_process_target_attr (tree args, const char*
pragma_or_attr)
if (len == 0)
{
- error ("malformed target %s value", pragma_or_attr);
+ error ("malformed target %s value", is_pragma);
You should probably have two strings like you did in every other instance:
if (is_pragma)
error ("malformed target pragma value");
else
error ("malformed target attribute value");
Everything else looks good to me (I'm the current French translator).
[Bug translation/80280] New: Missing closing quote (%>) c/semantics.c and c/c-typeck.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80280
Bug ID: 80280
Summary: Missing closing quote (%>) c/semantics.c and
c/c-typeck.c
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: fmarchal at perso dot be
Target Milestone: ---
The following four messages lack a closing quote (%>) somewhere after the
%<#pragma...
In c/semantics.c:8523
error ("%<#pragma omp cancel must specify one of "
"%<parallel%>, %<for%>, %<sections%> or %<taskgroup%> clauses");
In c/semantics.c:8560
error ("%<#pragma omp cancellation point must specify one of "
"%<parallel%>, %<for%>, %<sections%> or %<taskgroup%> clauses");
In c/c-typeck.c:11867
error_at (loc, "%<#pragma omp cancel must specify one of "
"%<parallel%>, %<for%>, %<sections%> or %<taskgroup%> "
"clauses");
In c/c-typeck.c:11906
error_at (loc, "%<#pragma omp cancellation point must specify one of "
"%<parallel%>, %<for%>, %<sections%> or %<taskgroup%> "
"clauses");
[Bug translation/80278] New: Messages with untranslated string fragment in config/i386/i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80278
Bug ID: 80278
Summary: Messages with untranslated string fragment in
config/i386/i386.c
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: fmarchal at perso dot be
Target Milestone: ---
In function ix86_option_override_internal() in config/i386/i386.c, several
messages are build like this:
error ("generic CPU can be used only for %stune=%s %s",
prefix, suffix, sw);
Here, sw is assigned an untranslated string literal:
/* Set up prefix/suffix so the error messages refer to either the command
line argument, or the attribute(target). */
if (main_args_p)
{
prefix = "-m";
suffix = "";
sw = "switch";
}
else
{
prefix = "option(\"";
suffix = "\")";
sw = "attribute";
}
Such messages can't be translated properly because sw isn't translated.
An easy fix might be to use sw=_("switch") and sw=_("attribute") but, if you do
that, please add a comment to let the translators know that the nth %s in the
message is replaced with the translation for "switch" or "attribute".
[Bug translation/80195] New: Message build from untranslated string concatenation in fortran/resolve.c:14529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80195 Bug ID: 80195 Summary: Message build from untranslated string concatenation in fortran/resolve.c:14529 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- In fortran/resolve.c at line 14529: if (sym->ts.type == BT_DERIVED && sym->ns->proc_name && sym->ns->proc_name->attr.flavor == FL_MODULE && !sym->ts.u.derived->attr.use_assoc && gfc_check_symbol_access (sym) && !gfc_check_symbol_access (sym->ts.u.derived) && !gfc_notify_std (GFC_STD_F2003, "PUBLIC %s %qs at %L of PRIVATE " "derived type %qs", (sym->attr.flavor == FL_PARAMETER) ? "parameter" : "variable", sym->name, >declared_at, sym->ts.u.derived->name)) return; The first %s is replaced with one of the untranslated strings literal "parameter" or "variable". That message can't be translated because it is constructed by concatenating strings fragments.
[Bug translation/80055] do not mark internal compiler error messages for i18n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80055 --- Comment #5 from Frederic Marchal --- (In reply to David Malcolm from comment #4) > Would this prefix be for the benefit of the user, or for translator? (or > both?) > > I believe that everywhere we're using internal_error, the diagnostics > machinery will add "internal compiler error: " as a prefix when the message > is emitted to the user, and I believe this prefix is translated. The prefix was meant for the user. Roland's suggestion was to reduce the translators workload by removing technical messages from the translation as users aren't supposed to see them and much less understand them. My opinion was that it would be rude to display an untranslated message to the user. But, to spare users some head scratching when faced with a message they are not supposed to understand, I suggested to clearly identify such messages as intended to the gcc development team. If internal_error messages are already clearly identified as such, then all is well from my point of view but you may want to argue about how unlikely it is for a final user to ever see one internal_error.
[Bug translation/80185] New: Message build from untranslated string concatenation in fortran/resolve.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80185
Bug ID: 80185
Summary: Message build from untranslated string concatenation
in fortran/resolve.c
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: fmarchal at perso dot be
Target Milestone: ---
In function resolve_fl_procedure() in fortran/resolve.conf, one can find this
code around line 12345 (nice line number BTW):
/* Check the result characteristics. */
if (!gfc_check_result_characteristics (sym, iface, errmsg, 200))
{
gfc_error ("%s between the MODULE PROCEDURE declaration "
"in module %s and the declaration at %L in "
"SUBMODULE %s", errmsg, module_name,
>declared_at, submodule_name);
return false;
}
The first %s is an untranslated string such as "Type mismatch in function
result (%s/%s)" or "ALLOCATABLE attribute mismatch in " among other things.
That kind of construct is impossible to translate even if errmsg were
translated.
This is going to be a real mess to fix because
gfc_check_result_characteristics() is used at several places.
[Bug fortran/38573] Missing markers for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573
--- Comment #13 from Frederic Marchal ---
(In reply to Roland Illig from comment #12)
> (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.
Ah yes, I see your point. The string literal may be translated with _() when it
is assigned to symstd_msg. It doesn't have to be translated later when
symstd_msg is assigned to symstd.
So moving _() is fine:
symstd_msg = _("available since Fortran 77");
if (symstd)
*symstd = symstd_msg;
Sorry, the misunderstanding was on my side. I was stuck with this pattern:
symstd_msg = N_("available since Fortran 77");
if (symstd)
*symstd = _(symstd_msg);
[Bug fortran/38573] Missing markers for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573
--- Comment #11 from Frederic Marchal ---
(In reply to Roland Illig from comment #9)
> (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.
I suspect a misunderstanding here. Forgive me if I state the obvious.
The fix is not to move the translation mark around.
String literals must be identified as to be translated by a human translator
(something like symstd_msg=N_("string")) in the source code. Then the string
must also be replaced with its translation at runtime by a call to
gettext(symstd_msg) (usually shortened as _(symstd_msg) by a define).
The above code does call _(symstd_msg) to translate the string at runtime (as
it should) but the string literals pointed to by symstd_msg are not marked as
translatable. Translators never see them. Therefore, when gettext() is passed
the string "available since Fortran 77", it can't find its translation in the
mo file.
In most cases, the two steps are combined in one call to _("string") that
contains both the string literal extracted by xgettext and the call to
gettext() to actually translate it at runtime.
[Bug fortran/38573] Missing markers for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573 Frederic Marchal changed: What|Removed |Added CC||roland.illig at gmx dot de --- Comment #8 from Frederic Marchal --- I hadn't noticed the missing "but is". I automatically understood the message like this when I read it in my head: "The intrinsic %qs declared INTRINSIC at %L is not available in the current standard settings but *is* available since Fortran 77" 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.
[Bug fortran/38573] Missing markers for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573
Frederic Marchal changed:
What|Removed |Added
CC||fmarchal at perso dot be
--- Comment #5 from Frederic Marchal ---
This issue is still present in gcc 7.
The strings assigned to symstd_msg in gfc_check_intrinsic_standard() should be
marked for translation.
As it is, the current code in fortran/resolve.c at line 1709 outputs an error
message containing one untranslated fragment:
/* Check it is actually available in the standard settings. */
if (!gfc_check_intrinsic_standard (isym, , false, sym->declared_at))
{
gfc_error ("The intrinsic %qs declared INTRINSIC at %L is not "
"available in the current standard settings but %s. Use "
"an appropriate %<-std=*%> option or enable "
"%<-fall-intrinsics%> in order to use it.",
sym->name, >declared_at, symstd);
return false;
}
I don't know how many languages could work around that string concatenation and
still present a meaningful message to the user but none can output a legible
message if %s isn't translated. Therefore, I recommend to mark the strings for
translation as a stopgap until a full i18n compatible solution is available.
I also suggest to write a comment for translators stating that %s is a string
such as "available since Fortran 77".
[Bug fortran/79859] diagnostics: argument quoted twice in "No initializer for allocatable compoonent"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79859 --- Comment #3 from Frederic Marchal --- My mistake, I simply removed the superfluous single quotes in the translated message. Problem solved with the translation. The original message is still doubly quoted in English though.
[Bug fortran/79859] diagnostics: argument quoted twice in "No initializer for allocatable compoonent"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79859 Frederic Marchal changed: What|Removed |Added CC||fmarchal at perso dot be --- Comment #2 from Frederic Marchal --- (In reply to Manuel López-Ibáñez from comment #1) > (In reply to Roland Illig from comment #0) > > 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. > > There may be quite a few of this or '%s'. Fortran didn't support %qs until > very recently. I think you are wrong. It isn't '%s' but '%qs'. It means quotes around a quoted string i.e. double quoted string. In English, the above message ends up as ''%s'' which might be acceptable. In French, the above message shows up as '« %s »' which is unacceptable. The quotes must be dropped around %qs in the source code located in function build_actual_constructor() near fortran/primary.c:2672.
[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79883 --- Comment #5 from Frederic Marchal --- I agree with your proposal to reword the messages. It is in line with what I did with the French translation to circumvent the problem of the attribute being used as a plain English word.
[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79883
Frederic Marchal changed:
What|Removed |Added
CC||fmarchal at perso dot be
--- Comment #3 from Frederic Marchal ---
I confirm this is a problem at two more places within the same
avr_set_current_function() function:
if (args && TREE_CODE (TREE_VALUE (args)) != VOID_TYPE)
error_at (loc, "%qs function cannot have arguments", isr);
if (TREE_CODE (ret) != VOID_TYPE)
error_at (loc, "%qs function cannot return a value", isr);
I had to degrade the French translation to accommodate the %qs. The correct
translation for "interrupt function" should have been "la fonction
d'interruption" but it is, instead, the ugly "la fonction avec l'attribut «
interrupt »".
Similarly, "signal function" should be "la fonction de traitement du signal"
instead of the silly looking "la fonction avec l'attribut « signal »".
The keyword idiom is correct in this instance though:
error_at (loc, "function attributes %qs, %qs and %qs are mutually"
" exclusive", "OS_task", "OS_main", isr);
Therefore, I suggest to replace the above two messages with
if (args && TREE_CODE (TREE_VALUE (args)) != VOID_TYPE) {
if (cfun->machine->is_interrupt)
error_at (loc, "%<interrupt%> function cannot have arguments");
else
error_at (loc, "%<signal%> function cannot have arguments");
}
if (TREE_CODE (ret) != VOID_TYPE) {
if (cfun->machine->is_interrupt)
error_at (loc, "%<interrupt%> function cannot return a value");
else
error_at (loc, "%<signal%> function cannot return a value");
}
And the one reported by Roland with
if (!STR_PREFIX_P (name, "__vector")) {
if (cfun->machine->is_interrupt)
warning_at (loc, OPT_Wmisspelled_isr, "%qs appears to be a misspelled "
"interrupt handler, missing __vector prefix", name);
else
warning_at (loc, OPT_Wmisspelled_isr, "%qs appears to be a misspelled "
"signal handler, missing __vector prefix", name);
}
[Bug c/79922] i18n: unnecessary plural form translation in "passing argument %d"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79922 Frederic Marchal changed: What|Removed |Added CC||fmarchal at perso dot be --- Comment #1 from Frederic Marchal --- As far as I can tell, the plural is not about "argument %i" but about "argument(s) %Z". In French, I translated that message as: Singular: "passé dans l'argument %Z" Plural: "passé dans les arguments %Z" I expect %Z to be a list of some sort.
[Bug fortran/79861] i18n: add translator comment for "%s !$ACC LOOP loops not perfectly nested at %L"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79861 Frederic Marchal changed: What|Removed |Added CC||fmarchal at perso dot be --- Comment #1 from Frederic Marchal --- %s can be replaced with the untranslated texts "tiled" or "collapsed". That's not translator friendly and it introduces a discrepancy between the messages where "tiled loop" or "collapsed loop" are translated (because they appear verbatim) and those where they are not (due to the %s placeholder). There are four such messages using the "clause" variable in resolve_oacc_nested_loops() that need to be fixed.
[Bug translation/80055] do not mark internal compiler error messages for i18n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80055 Frederic Marchal changed: What|Removed |Added CC||fmarchal at perso dot be --- Comment #2 from Frederic Marchal --- I do not concur with this request. If a message might be visible to the end user, it is best to translate it. If gcc outputs an English message in the middle of otherwise translated messages such as "import_iso_c_binding_module(): Unable to create symbol for %s", it looks like the translator didn't do his job properly. I translated the above message as "import_iso_c_binding_module(): Impossible de créer le symbole pour %s" The end user may have no clue as to what the message means but, at least, he/she is insulted in his/her own language :-) I suggest instead that internal messages be identified as such. Some other messages begin with "Internal error". I would favor that solution for messages not meant to the end user.
[Bug translation/79705] New: cp/decl.c message not marked for translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79705
Bug ID: 79705
Summary: cp/decl.c message not marked for translation
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: fmarchal at perso dot be
Target Milestone: ---
In cp/decl.c, inside function check_redeclaration_exception_specification(),
one can find the code below where the "declaration of %qF has a different
exception specifier" text isn't translated but the "from previous declaration
%qF" text following it is translated.
/* [except.spec]
If any declaration of a function has an exception-specification,
all declarations, including the definition and an explicit
specialization, of that function shall have an
exception-specification with the same set of type-ids. */
if (! DECL_IS_BUILTIN (old_decl)
&& !comp_except_specs (new_exceptions, old_exceptions, ce_normal))
{
const char *msg
= "declaration of %qF has a different exception specifier";
bool complained = true;
location_t new_loc = DECL_SOURCE_LOCATION (new_decl);
if (DECL_IN_SYSTEM_HEADER (old_decl))
complained = pedwarn (new_loc, OPT_Wsystem_headers, msg, new_decl);
else if (!flag_exceptions)
/* We used to silently permit mismatched eh specs with
-fno-exceptions, so make them a pedwarn now. */
complained = pedwarn (new_loc, OPT_Wpedantic, msg, new_decl);
else
error_at (new_loc, msg, new_decl);
if (complained)
inform (DECL_SOURCE_LOCATION (old_decl),
"from previous declaration %qF", old_decl);
}
Either translate both or translate none. I guess they should be both
translated.
[Bug translation/79453] New: Translator unfriendly string in avr_pgm_check_var_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79453
Bug ID: 79453
Summary: Translator unfriendly string in avr_pgm_check_var_decl
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: fmarchal at perso dot be
Target Milestone: ---
In gcc/config/avr/avr.c, at line, 9831 (inside avr_pgm_check_var_decl()), one
can find this error message:
error ("pointer targeting address space %qs must be const"
" in %s %q+D",
avr_addrspace[as].name, reason, node);
The "reason" variable contains an untranslated text such as "variable",
"function parameter", "return type of function", and so on. Building a string
out of fragments doesn't play well at all with translations.
I'm afraid every reason should have its own error message.
[Bug translation/79248] New: Typo in symtab.c:1032 "byt" instead of "but"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79248
Bug ID: 79248
Summary: Typo in symtab.c:1032 "byt" instead of "but"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: fmarchal at perso dot be
Target Milestone: ---
In gcc/symtab.c at line 1032:
if (analyzed && !definition)
{
error ("node is analyzed byt it is not a definition");
error_found = true;
}
There is a typo. "byt" should very likely be "but".
[Bug translation/79208] Typo in gcc/ipa-devirt.c:1631
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79208
--- Comment #2 from Frederic Marchal ---
If the printed message is supposed to be concatenated with something else, then
there is another problem with every other messages printed by function
odr_types_equivalent_p()! All the messages I could see are like these one:
G_("a different type is defined in another translation unit"));
G_("an enum with different value name"
" is defined in another translation unit"));
G_("virtual table layout differs "
"in another translation unit"));
The messages would incorrectly merge the beginning of the string with the
previously printed name without any space.
So, either the message starting with "s" doesn't do what is expected or every
other message don't do what is expected.
[Bug translation/79208] New: Typo in gcc/ipa-devirt.c:1631
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79208
Bug ID: 79208
Summary: Typo in gcc/ipa-devirt.c:1631
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: fmarchal at perso dot be
Target Milestone: ---
I believe there is a typo in the warning message reported in ipa-devirt.c at
line 1631:
if (DECL_VIRTUAL_P (f1) != DECL_VIRTUAL_P (f2))
{
warn_odr (t1, t2, f1, f2, warn, warned,
G_("s definition that differs by virtual "
"keyword in another translation unit"));
return false;
}
The first lone "s" may be a "a". Or the whole word ("same" maybe) is truncated.
The Swedish translator opted for a "a".
[Bug translation/79183] Hard coded plurals in gimple-ssa-sprintf.c:2050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
--- Comment #1 from Frederic Marchal ---
Yet another hard coded plural in the same file at line 2286:
inform (callloc,
(nbytes + exact == 1
? G_("format output %wu byte into a destination of size %wu")
: G_("format output %wu bytes into a destination of size %wu")),
nbytes + exact, info.objsize);
[Bug translation/79183] New: Hard coded plurals in gimple-ssa-sprintf.c:2050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
Bug ID: 79183
Summary: Hard coded plurals in gimple-ssa-sprintf.c:2050
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: fmarchal at perso dot be
Target Milestone: ---
gimple-ssa-sprintf.c contains two hard coded plurals starting from line 2050:
const char* fmtstr
= (info.bounded
? (1 < fmtres.range.min
? G_("%<%.*s%> directive output truncated while writing "
"%wu bytes into a region of size %wu")
: G_("%<%.*s%> directive output truncated while writing "
"%wu byte into a region of size %wu"))
: (1 < fmtres.range.min
? G_("%<%.*s%> directive writing %wu bytes "
"into a region of size %wu")
: G_("%<%.*s%> directive writing %wu byte "
"into a region of size %wu")));
Beside, the plural rules are wrong for English. Plural should be used if
fmtres.range.min is zero.
[Bug translation/79100] New: Superfluous % in messages from cfgloop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79100
Bug ID: 79100
Summary: Superfluous % in messages from cfgloop.c
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: fmarchal at perso dot be
Target Milestone: ---
In cfgloop.c, starting at line 1424, several messages contain a superfluous %
character:
if (!bb_loop_header_p (loop->header))
{
error ("loop %d%'s header is not a loop header", i);
err = 1;
}
Variable "i" is the loop number. It is not reported as a percentage at other
places.
Messages like this can be found between line 1424 and line 1472.
[Bug translation/79093] New: Hard coded plural in builtins.c:3203
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79093
Bug ID: 79093
Summary: Hard coded plural in builtins.c:3203
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: fmarchal at perso dot be
Target Milestone: ---
The following code is found in builtins.c:
warning_at (loc, opt,
(uwir0 == 1
? G_("%K%qD: writing %wu byte into a region "
"of size %wu overflows the destination")
: G_("%K%qD writing %wu bytes into a region "
"of size %wu overflows the destination")),
exp, get_callee_fndecl (exp), uwir0,
tree_to_uhwi (objsize));
Assuming singular is only for a quantity == 1 is wrong. See
https://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Plural-forms.html.
If ngettext can't be used, please use only one string for both singular and
plural, like this: "%K%qD: writing %wu byte(s) into a region ".
BTW, the plural lacks a colon after %K%qD.
[Bug translation/48555] [fr] gibberish warning (déréférencement du pointeur type-punned brisera les strictes d'aliases)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48555 Frederic Marchal changed: What|Removed |Added CC||fmarchal at perso dot be --- Comment #3 from Frederic Marchal --- Messages containing "type-punned" have been updated in version 7.1-b20170101 (http://translationproject.org/PO-files/fr/gcc-7.1-b20170101.fr.po) and backported to version 6.2.0 (http://translationproject.org/PO-files/fr/gcc-6.2.0.fr.po). It seems "type-punned" is usually referred as "transtypage à la barbare". So, it is what I used in the three messages using "type-punned". I also fixed the will/may issue.
[Bug translation/64934] The french text of --version is not proper french
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64934 Frederic Marchal changed: What|Removed |Added CC||fmarchal at perso dot be --- Comment #3 from Frederic Marchal --- I partly changed the French translation as requested by this bug report but I haven't copy/pasted the official text because I don't want the translation to change the intent of the original message. In particular, I haven't added a text saying that the software can be copied, redistributed and modified. The English message should be modified if it really is desirable to say so. The new message is available in version 7.1-b20170101 (http://translationproject.org/PO-files/fr/gcc-7.1-b20170101.fr.po). It was backported to version 6.2.0 (http://translationproject.org/PO-files/fr/gcc-6.2.0.fr.po).
[Bug translation/79020] New: translatable string typo in params.def:1173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79020 Bug ID: 79020 Summary: translatable string typo in params.def:1173 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- "Use direct poisoning/unpoisoning intructions for variables smaller or equal to this number." There is a missing letter in "instructions". Message found in ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170101/gcc-7-20170101.tar.bz2 proposed to translators.
[Bug translation/79019] New: translatable string typo in cif-code.def:141
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79019 Bug ID: 79019 Summary: translatable string typo in cif-code.def:141 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- The message "caller is instrumetnation thunk" contains an error in "instrumentation". Message found in ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170101/gcc-7-20170101.tar.bz2 proposed to translators.
[Bug other/79018] New: translatable string typo in params.def:1105
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79018 Bug ID: 79018 Summary: translatable string typo in params.def:1105 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- The message "Maximum number of constant stores to merge in thestore merging pass" lacks a space in "the store" I presume. Message found in ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170101/gcc-7-20170101.tar.bz2 proposed to translators.
[Bug translation/78745] Truncated messages in po file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78745 --- Comment #6 from Frederic Marchal --- More truncated lines in gcc/config/arm/arm.opt at line 231 and 266,
[Bug translation/78745] Truncated messages in po file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78745 --- Comment #5 from Frederic Marchal --- More truncated lines in gcc/config/s390/s390.opt at lines 116, 178, 195,
[Bug c/78941] New: Typo in maccumulate-args description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78941 Bug ID: 78941 Summary: Typo in maccumulate-args description Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- In gcc/config/avr/avr.opt at line 77, the description for maccumulate-args is maccumulate-args Target Report Mask(ACCUMULATE_OUTGOING_ARGS) Accumulate outgoing function arguments and acquire/release the needed stack space for outpoing function arguments in function prologue/epilogue. Without this option, outgoing arguments are pushed before calling a function and popped afterwards. This option can lead to reduced code size for functions that call many functions that get their arguments on the stack like, for example printf. Notice the "outpoing" that should very likely be "outgoing".
[Bug c/78922] New: Comment submitted for translation in stringop.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78922 Bug ID: 78922 Summary: Comment submitted for translation in stringop.opt Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- The generated gcc/po/gcc.pot file contains the three following messages: #: config/i386/stringop.opt:8 msgid "the Free Software Foundation; either version 3, or (at your option)" msgstr "" #: config/i386/stringop.opt:13 msgid "MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the" msgstr "" #: config/i386/stringop.opt:18 msgid "see <http://www.gnu.org/licenses/>. */" msgstr "" These messages are coming from the copyright header in gcc/config/i386/stringop.opt. They must not appear in gcc.pot as they do not correspond to messages to be translated.
[Bug translation/78745] Truncated messages in po file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78745 --- Comment #4 from Frederic Marchal --- More multi-line descriptions in gcc/config/i386/i386.opt at line 567, 577, 844.
[Bug c/78876] New: Wording error in Wpedantic-ms-format description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78876 Bug ID: 78876 Summary: Wording error in Wpedantic-ms-format description Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- The description for Wpedantic-ms-format in gcc/config/i386/mingw.opt at line 29 is: "Warn about none ISO msvcrt scanf/printf width extensions." I'm pretty sure it should be "non-ISO" or something similar.
[Bug translation/78745] Truncated messages in po file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78745 --- Comment #3 from Frederic Marchal --- One more truncated entry in gcc/config/aarch64/aarch64.opt at line 154.
[Bug translation/78745] Truncated messages in po file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78745 --- Comment #2 from Frederic Marchal --- Same problem in gcc/config/bfin/bfin.opt at lines 56 and 69.
[Bug translation/78745] New: Truncated messages in po file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78745 Bug ID: 78745 Summary: Truncated messages in po file Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- Multiline parameter descriptions in gcc/c-family/c.opt are truncated in po files provided to translators. For instance, on line 1053: fcheck-pointer-bounds C ObjC C++ ObjC++ LTO Report Var(flag_check_pointer_bounds) Add Pointer Bounds Checker instrumentation. fchkp-* flags are used to control instrumentation. Currently available for C, C++ and ObjC. is seen by the translator as #: c-family/c.opt:1055 msgid "Add Pointer Bounds Checker instrumentation. fchkp-* flags are used to" That message can't be translated as only the first line is visible.
[Bug c/78732] New: Wrong description for Wendif-labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78732 Bug ID: 78732 Summary: Wrong description for Wendif-labels Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fmarchal at perso dot be Target Milestone: --- In file gcc/c-family/c.opt, at line 421, the description for Wendif-labels is "Warn about stray tokens after #elif and #endif." I believe the message is about #else and #endif instead of #elif. Tokens are expected after #elif.
