[Libvir] many more translatable strings need to be marked

[Daniel Veillard]

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).

> > worldwide, and I'm afraid they are gonna be quite annoyed when facing such
> > strings. There is a small limit to automatically forcing eveything into
> > the transaltion system, which is we should avoid pushing there unstranslatable
> > strings, either by human examination (which basically breaks the attempt of
> > automatic checking) or by rewriting all strings to be proper english and
> > not untranalsatable pseudocode. The point too is that this untranslatable
> > pseudocode is probably the right thing to to use, making it an english sentence
> > won't improve user experience much nor make it easier to fix the problem
> > if it appears.
> >
> >   Isn't that going a bit too far ?
> >
> >> -        remoteDispatchError (client, req, "network not found");
> >> +        remoteDispatchError (client, req, "%s", _("network not found"));
> >
> >   Though this kind of errors make sense to translate. What doesn't make sense
> > is that the same string (and actually the same code) is repeated dozens of
> > time, better replace them with a single remoteDispatchNetworkError(client, req)
> > and generate a single translatable string.
> 
> You could have said the same thing about the change-set
> that added all of those diagnostics.

  Oh, sure :-) 

> IMHO, this issue is independent, and need not delay my change.
> If you're so inclined, would you be interested in taking
> on the task of factoring out that duplication?

  yeah, I could do that.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/