This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Support for %d$c format specifier in diagnostics.c
Ishikawa <ishikawa@yk.rim.or.jp> writes:
> --- begin quote from ABOUT-GCC-NLS ---
> Not all of GCC's diagnostic messages have been internationalized.
> Programs
> like `genattr' (in fact all gen* programs) are not internationalized, as
> their users are GCC maintainers who typically need to be able to read
> English anyway; internationalizing them would thus entail needless work
> for
> the human translators. Messages used for debugging, such as used in
> dumped
> tables, should also not be translated.
>
> The GCC library should not contain any messages that need
> internationalization, because it operates below the internationalization
> library.
>
> Unlike some other GNU programs, the GCC sources contain few instances
> of explicit translation calls like _("string"). Instead, the
> diagnostic printing routines automatically translate their arguments.
> For example, GCC source code should not contain calls like `error
> (_("unterminated comment"))'; it should contain calls like `error
> ("unterminated comment")' instead, as it is the `error' function's
> responsibility to translate the message before the user sees it.
>
> --- end quote ---
>
> I am not sure if the tree printing routines require I18N/L10N.
> I agree witht the first two paragraphs in the quotes.
>
> After reading the third paragraph in the above quote,
> I am not sure if there are entry points in diagnostic.c which
> do NOT use the translation and end up with output_format() with
> the original format string intact.
> But I guess there must be such entry points.
There are not supposed to be any such entry points. All of the
strings that are deliberately not translated, do not go through
diagnostic.c. Everything that diagnostic.c prints is supposed to
be subject to translation.
> Such usage of output_format() won't need positional parameters.
> I have a feeling that tree dump and RTL dump(?) won't need
> such translation either.
You're correct that debugging dumps do not need translation, but
they use their own printers, so you needn't worry about it.
Tracing through diagnostic.c can be confusing. There is a convention
that may help: A function with an argument 'const char *msgid' has
responsibility for getting the string translated. This may happen
either by a direct call to gettext (which may be written using a
shorthand macro: _(msgid)), or by passing the string to another
function which will take responsibility.
In diagnostic.c, the buck stops (mostly) with diagnostic_set_info.
Another convention which is much less widely used: a function with
an argument 'const char *msgstr' expects to receive a string that
has already been translated.
More generally, string variables named 'msgid' are intended to be
translated, but haven't yet, and string variables named 'msgstr' have
already been translated.
zw