[libvirt] [PATCH 01/30] Don't mark log messages for translation
Daniel P. Berrange
berrange at redhat.com
Tue Apr 6 09:53:40 UTC 2010
On Mon, Apr 05, 2010 at 07:18:42PM +0200, Matthias Bolte wrote:
> 2010/4/5 Eric Blake <eblake at redhat.com>:
> > On 04/04/2010 11:36 AM, Matthias Bolte wrote:
> >> Also remove manually added function names from log messages, the logging
> >> macros already record them and the logging framework outputs them.
> >
> > I see in [1] where the translation was first added, but no justification
> > there for why log messages are marked, nor in your patch why they should
> > not be marked. I'm not opposed to the idea, but I think it would make a
> > lot more sense if the commit message explained exactly why we don't
> > think log messages deserve translations.
> >
> > [1] https://www.redhat.com/archives/libvir-list/2009-January/msg00005.html
> >
> >> +++ b/cfg.mk
> >> @@ -168,28 +168,16 @@ sc_prohibit_gethostby:
> >> # |grep -vE '^(qsort|if|close|assert|fputc|free|N_|vir.*GetName|.*Unlock|virNodeListDevices|virHashRemoveEntry|freeaddrinfo|.*[fF]ree|xdrmem_create|xmlXPathFreeObject|virUUIDFormat|openvzSetProgramSentinal|polkit_action_unref)$'
> >>
> >> msg_gen_function =
> >> -msg_gen_function += DEBUG0
> >
> > For example, I can easily see why DEBUG0 does not need translation (it
> > is for developers, and should never be expanded into a log message in a
> > distro's installation, so why waste the translator's efforts on it)...
> >
> >> -msg_gen_function += DISABLE_fprintf
> >> -msg_gen_function += ERROR
> >> -msg_gen_function += ERROR0
> >> -msg_gen_function += REMOTE_DEBUG
> >> msg_gen_function += ReportError
> >> -msg_gen_function += VIR_FREE
> >> -msg_gen_function += VIR_INFO
> >
> > But the name VIR_INFO seems like it might be something the end user may
> > eventually want to see in their own language. Maybe the reasoning that
> > I'm not seeing here is that grep-ability of system logs is more
> > important than translating system logs into the user's language?
> >
> >> @@ -236,7 +223,7 @@ func_re := ($(func_or))
> >> # "%s", _("no storage vol w..."
> >> sc_libvirt_unmarked_diagnostics:
> >> @grep -nE \
> >> - '\<$(func_re) \([^"]*"[^"]*[a-z]{3}' $$($(VC_LIST_EXCEPT)) \
> >> + '\<$(func_re) *\([^"]*"[^"]*[a-z]{3}' $$($(VC_LIST_EXCEPT)) \
> >> | grep -v '_''(' && \
> >> { echo '$(ME): found unmarked diagnostic(s)' 1>&2; \
> >> exit 1; } || :
> >
> > ACK to this hunk, independently of the overall issue on why we need this
> > patch.
> >
> >> diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
> >> index 208ffca..68fe95a 100644
> >> --- a/daemon/libvirtd.c
> >> +++ b/daemon/libvirtd.c
> >> @@ -272,7 +272,7 @@ remoteCheckCertFile(const char *type, const char *file)
> >> struct stat sb;
> >> if (stat(file, &sb) < 0) {
> >> char ebuf[1024];
> >> - VIR_ERROR(_("Cannot access %s '%s': %s"),
> >> + VIR_ERROR("Cannot access %s '%s': %s",
> >> type, file, virStrerror(errno, ebuf, sizeof ebuf));
> >> return -1;
> >> }
> >
> > Again, this seems like something the user would want to see in their own
> > language. So while the rest of this patch looks mechanically correct,
> > I'm hesitant to give an ACK without more reasoning on which functions
> > deserve to bypass translation; it may requiring reducing the scope of
> > this patch.
> >
>
> DanPB's argument [1] against marking log messages for translation was
> mainly that they aren't meant for the end user, but for debugging
> purpose and to be included in bug reports.
It would also put a huge burden on the translators since these log messages
are not easily translated & there are a hell of alot of them
> On the other hand one can argue about VIR_ERROR on the libvirtd side
> where it's used to report critical errors like the one you quoted
> above.
I could probably be convinced about VIR_ERROR translation :-)
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
More information about the libvir-list
mailing list