Re: many more translatable strings need to be marked

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
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.
  Maybe all memory errors from the module should be factored too,

  So I'm afraid the patch goes either a bit too far, or not far enough,

Daniel

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

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]