[Libvir] many more translatable strings need to be marked

Jim Meyering jim at meyering.net
Fri Feb 29 15:54:38 UTC 2008


Daniel Veillard <veillard at redhat.com> wrote:

> On Fri, Feb 29, 2008 at 04:15:47PM +0100, Jim Meyering wrote:
>> Daniel Veillard <veillard at redhat.com> wrote:
>> > On Fri, Feb 29, 2008 at 03:48:18PM +0100, Jim Meyering wrote:
>> >> I've found many more strings that should be marked for translation.
>> >> The first part of this change is to add to the list of
>> >> diagnostic-printing function names in Makefile.maint and to
>> >> make that list more readable.
>> >>
>> >> I marked some strings, but am leaving the rest, for now.  Running "make
>> >> sc_unmarked_diagnostics" shows over 300 strings remaining to be marked
>> >> with _(...).  However, while marking them is a big step, it's not all.
>> >> Once they're all marked, then we'll have to go back and with the help
>> >> of the right build options (--disable-nls and -Wformat -Wformat-security),
>> >> or just some judicious grepping through your patch,
>> >> add "%s" before each _("...") string that contains no "%" directive.
>> >
>> >   While I undertand the point maybe it's pushed a bit too much, or not enough
>> >
>> >>      if (args->maxnames > REMOTE_DOMAIN_NAME_LIST_MAX) {
>> >>          remoteDispatchError (client, req,
>> >> -                             "maxnames > REMOTE_DOMAIN_NAME_LIST_MAX");
>> >> +                             "%s", _("maxnames > REMOTE_DOMAIN_NAME_LIST_MAX"));
>> >
>> >    The net effect of soem of those is that strings which are basically
>> > untranslatable will be pushed to the small army of benevolent translators
>>
>> I can easily (and possibly automatically) mark such strings with a
>> specially formatted comment saying they are not meant to be translated.
>> gettext tools propagate such comments so that translators will see them,
>> and they won't be bothered.
>>
>> Would you be satisfied simply to add such a comment to messages that are
>> of the form "SYM < SYM" or "SYM > SYM" ?
>
>   That could be one way, yes
>   But maybe we should consider those as internal errors (which I think they are)
> and report them as such, the string itself is probably as well left out of
> gettext entierely (but the error massage saying it was an internal error,
> that one need localization).

I agree that it'd be nice to improve those diagnostics.

How about if I mark the existing ones for now, with the proposed added
comments?  The comments can then serve as a reminder to rewrite them later.

    /* FIXME: rewrite this diagnostic */
    /* TRANSLATORS: no need to translate */




More information about the libvir-list mailing list