[Libvir] [PATCH] fix typos (part3)
Hi, I guess this is the last one for libvirt. docs/errors.html |6 +++--- docs/format.html | 14 +++--- docs/index.html |2 +- docs/news.html|2 +- docs/python.html |2 +- docs/storage.html | 20 ++-- include/libvirt/libvirt.h | 18 +- include/libvirt/libvirt.h.in | 18 +- include/libvirt/virterror.h |4 ++-- python/libvir.c | 10 +- python/libvirt-python-api.xml |4 ++-- python/libvirt_wrap.h |2 +- qemud/event.c |4 ++-- qemud/event.h |8 qemud/libvirtd.conf |4 ++-- qemud/mdns.c |2 +- qemud/mdns.h |4 ++-- qemud/remote.c|2 +- 18 files changed, 63 insertions(+), 63 deletions(-) I wrote a small gnulib document on ja.wikipedia http://ja.wikipedia.org/wiki/Gnulib Thanks Atsushi SAKAI fix_typos_3.patch Description: Binary data -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] ignore leading zeros, too [Change MAC address to case insensitive
Daniel P. Berrange [EMAIL PROTECTED] wrote:
On Tue, Feb 26, 2008 at 12:13:43PM +0100, Jim Meyering wrote:
Richard W.M. Jones [EMAIL PROTECTED] wrote:
I'll apply this today (using our STRCASEEQ macros) if no one else
objects.
What do you think about using a MAC-address-specific comparison
function? I.e., one that is not only case-independent, but that also
knows leading zeros are unnecessary?
i.e., it would admit that these two match:
00:0A:FF:3A:00:09
0:a:ff:3a:0:9
Yes, we should add a helper function for comparing mac addresses for
equality.
With this patch, they now match:
Also ignore leading zeros when comparing MAC addresses.
* src/util.c: Include ctype.h.
(TOLOWER): Define.
(__virMacAddrCompare): Rewrite to also ignore leading zeros.
Signed-off-by: Jim Meyering [EMAIL PROTECTED]
---
src/util.c | 34 +-
1 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/src/util.c b/src/util.c
index 4d61540..edaa5aa 100644
--- a/src/util.c
+++ b/src/util.c
@@ -35,6 +35,7 @@
#include sys/stat.h
#include sys/wait.h
#include string.h
+#include ctype.h
#ifdef HAVE_PATHS_H
#include paths.h
@@ -50,6 +51,8 @@
#define MAX_ERROR_LEN 1024
+#define TOLOWER(Ch) (isupper (Ch) ? tolower (Ch) : (Ch))
+
#define virLog(msg...) fprintf(stderr, msg)
#ifndef PROXY
@@ -654,14 +657,35 @@ virParseNumber(const char **str)
return (ret);
}
-/* Use this function when comparing two MAC addresses. It deals with
- * string case compare and will eventually be extended to understand
- * that 01:02:03:04:05:06 is the same as 1:2:3:4:5:6.
+/* Compare two MAC addresses, ignoring differences in case,
+ * as well as leading zeros.
*/
int
-__virMacAddrCompare (const char *mac1, const char *mac2)
+__virMacAddrCompare (const char *p, const char *q)
{
-return strcasecmp (mac1, mac2);
+unsigned char c, d;
+do {
+while (*p == '0' isxdigit (p[1]))
+++p;
+while (*q == '0' isxdigit (q[1]))
+++q;
+c = TOLOWER (*p);
+d = TOLOWER (*q);
+
+if (c == 0 || d == 0)
+break;
+
+++p;
+++q;
+} while (c == d);
+
+if (UCHAR_MAX = INT_MAX)
+return c - d;
+
+/* On machines where 'char' and 'int' are types of the same size, the
+ difference of two 'unsigned char' values - including the sign bit -
+ doesn't fit in an 'int'. */
+return (c d ? 1 : c d ? -1 : 0);
}
/*
--
1.5.4.3.326.g7655e3
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Re: ignore leading zeros, too [Change MAC address to case insensitive
On Fri, Feb 29, 2008 at 12:59:39PM +0100, Jim Meyering wrote: diff --git a/src/util.c b/src/util.c index 4d61540..edaa5aa 100644 --- a/src/util.c +++ b/src/util.c @@ -35,6 +35,7 @@ #include sys/stat.h #include sys/wait.h #include string.h +#include ctype.h I thought we're not supposed to be using ctype? Anyway, +1 the patch looks fine. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Re: ignore leading zeros, too [Change MAC address to case insensitive
On Fri, Feb 29, 2008 at 01:33:42PM +0100, Jim Meyering wrote: Richard W.M. Jones [EMAIL PROTECTED] wrote: I thought we're not supposed to be using ctype? As far as i know, #include ctype.h is still the only way to use the things it specifies (tolower, isupper, isxdigit, etc.) Maybe you're thinking of strings.h? I was thinking that the ctype functions like isxdigit were deprecated. Don't worry, you know lots more about this than me. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] [PATCH] fix typos (part3)
On Fri, Feb 29, 2008 at 07:06:08PM +0900, Atsushi SAKAI wrote: Hi, I guess this is the last one for libvirt. docs/errors.html |6 +++--- docs/format.html | 14 +++--- docs/index.html |2 +- docs/news.html|2 +- docs/python.html |2 +- docs/storage.html | 20 ++-- include/libvirt/libvirt.h | 18 +- include/libvirt/libvirt.h.in | 18 +- include/libvirt/virterror.h |4 ++-- python/libvir.c | 10 +- python/libvirt-python-api.xml |4 ++-- python/libvirt_wrap.h |2 +- qemud/event.c |4 ++-- qemud/event.h |8 qemud/libvirtd.conf |4 ++-- qemud/mdns.c |2 +- qemud/mdns.h |4 ++-- qemud/remote.c|2 +- 18 files changed, 63 insertions(+), 63 deletions(-) Thanks, I'm going to apply all of this. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] Re: ignore leading zeros, too [Change MAC address to case insensitive
Richard W.M. Jones [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 12:59:39PM +0100, Jim Meyering wrote: diff --git a/src/util.c b/src/util.c index 4d61540..edaa5aa 100644 --- a/src/util.c +++ b/src/util.c @@ -35,6 +35,7 @@ #include sys/stat.h #include sys/wait.h #include string.h +#include ctype.h Anyway, +1 the patch looks fine. Hi Rich, Thanks for the review. I thought we're not supposed to be using ctype? As far as i know, #include ctype.h is still the only way to use the things it specifies (tolower, isupper, isxdigit, etc.) Maybe you're thinking of strings.h? -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] many more translatable strings need to be marked
Daniel Veillard [EMAIL PROTECTED] 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 ?
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.
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?
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] many more translatable strings need to be marked
On Fri, Feb 29, 2008 at 10:02:35AM -0500, Daniel Veillard wrote:
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.
So I'm responsible for the above string :-)
Some of these, eg. ret.names.names_len maxnames are basically
internal errors. You would only get those errors if the remote server
was trying to play funny games with you. The error is really server
is broken or is trying to compromise your client, but we need the
extra detail in order to debug the issue.
Others, such as the one you highlight above
(maxnames REMOTE_DOMAIN_NAME_LIST_MAX) are not really something
that a non-programmer could do much about. In this case it indicates
that a hard limit inside the remote protocol would need to be
increased in order for the request to succeed -- ie. you'd have to
edit remote_protocol.x and rebuild both the client and server and then
your client wouldn't be interoperable with a standard server. Can
this be meaningfully translated into something an end user can do
anything about? And if they're not an end user but a programmer,
they'd need to speak English to understand the libvirt source.
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.
I thought xgettext (or whatever it is which generates the .pot file)
would combine equal strings?
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] many more translatable strings need to be marked
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/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] many more translatable strings need to be marked
On Fri, Feb 29, 2008 at 04:15:47PM +0100, Jim Meyering wrote:
Daniel Veillard [EMAIL PROTECTED] 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/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[Libvir] many more translatable strings need to be marked
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.
Mark many more strings for translation.
* Makefile.maint (err_func_re): Add to the list and make it readable.
* po/POTFILES.in: Add src/util.c and src/xm_internal.c, and sort.
Signed-off-by: Jim Meyering [EMAIL PROTECTED]
---
Makefile.maint| 32 +++-
po/POTFILES.in| 10 ++-
qemud/remote.c| 197 +
src/storage_backend.c |2 +-
src/util.c|2 +-
src/xm_internal.c | 16 +++--
6 files changed, 147 insertions(+), 112 deletions(-)
diff --git a/Makefile.maint b/Makefile.maint
index 92cdf29..14a2ac5 100644
--- a/Makefile.maint
+++ b/Makefile.maint
@@ -299,8 +299,30 @@ sc_two_space_separator_in_usage:
echo $(ME): an option and its description; \
12; exit 1; } || :
-err_func_re = \
-(DISABLE_fprintf|qemudLog|(xmlRpc|vir(Xend|XML|Hash|Conf|Test|LibConn|StorageReport))Error)
+msg_gen_function = \
+ DISABLE_fprintf \
+ virXendError \
+ virXMLError \
+ virHashError \
+ virConfError \
+ virTestError \
+ virLibConnError \
+ virStorageReportError\
+ virxmlRpcError \
+ xenXMError \
+ virXenError \
+ ReportError \
+ testError\
+ virLog \
+ qemudLog \
+ openvzLog\
+ virStorageLog\
+ qemudReportError \
+ remoteDispatchError \
+ error
+
+func_or := $(shell printf '$(msg_gen_function)'|tr -s '[[:space:]]' '|')
+func_re := ($(func_or))
# Look for diagnostics that aren't marked for translation.
# This won't find any for which error's format string is on a separate line.
@@ -309,12 +331,12 @@ err_func_re = \
#%s, _(no storage vol w...
sc_unmarked_diagnostics:
@grep -nE \
- '\(vshError|error) \([^]*[^]*[a-z]{3}' $$($(CVS_LIST_EXCEPT))
\
+ '\$(func_re) \([^]*[^]*[a-z]{3}' $$($(CVS_LIST_EXCEPT)) \
| grep -v '_''('\
{ echo '$(ME): found unmarked diagnostic(s)' 12;\
exit 1; } || :
- @{ grep -nE '\$(err_func_re) *\(.*;$$' $$($(CVS_LIST_EXCEPT)); \
- grep -A1 -nE '\$(err_func_re) *\(.*,$$' $$($(CVS_LIST_EXCEPT)); } \
+ @{ grep -nE '\$(func_re) *\(.*;$$' $$($(CVS_LIST_EXCEPT)); \
+ grep -A1 -nE '\$(func_re) *\(.*,$$' $$($(CVS_LIST_EXCEPT)); } \
| sed 's/_([^][^]*//;s/[ ]%s//' \
| grep '[ ]' \
{ echo '$(ME): found unmarked diagnostic(s)' 12;\
diff --git a/po/POTFILES.in b/po/POTFILES.in
index 0aafd2e..b619aa2 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -1,6 +1,6 @@
gnulib/lib/gai_strerror.c
-qemud/remote.c
qemud/qemud.c
+qemud/remote.c
src/conf.c
src/console.c
src/hash.c
@@ -10,20 +10,22 @@ src/proxy_internal.c
src/qemu_conf.c
src/qemu_driver.c
src/remote_internal.c
+src/sexpr.c
src/storage_backend.c
+src/storage_backend_disk.c
src/storage_backend_fs.c
-src/storage_backend_logical.c
src/storage_backend_iscsi.c
-src/storage_backend_disk.c
+src/storage_backend_logical.c
src/storage_conf.c
src/storage_driver.c
-src/sexpr.c
src/test.c
+src/util.c
src/uuid.c
src/virsh.c
src/virterror.c
src/xen_internal.c
src/xend_internal.c
+src/xm_internal.c
src/xml.c
src/xmlrpc.c
src/xs_internal.c
diff --git a/qemud/remote.c b/qemud/remote.c
index 014fe65..a8f8eb4 100644
--- a/qemud/remote.c
+++ b/qemud/remote.c
@@ -102,32 +102,34 @@ remoteDispatchClientRequest (struct qemud_server *server,
xdrmem_create (xdr, client-buffer, client-bufferLength, XDR_DECODE);
if (!xdr_remote_message_header (xdr, req)) {
-remoteDispatchError (client, NULL, xdr_remote_message_header);
+remoteDispatchError (client, NULL, %s,
_(xdr_remote_message_header));
xdr_destroy (xdr);
return;
}
/* Check version, etc. */
if (req.prog != REMOTE_PROGRAM) {
-remoteDispatchError (client, req, program mismatch (actual %x,
expected %x),
+remoteDispatchError (client, req,
+ _(program mismatch (actual %x, expected %x)),
Re: [Libvir] many more translatable strings need to be marked
Daniel Veillard [EMAIL PROTECTED] wrote:
On Fri, Feb 29, 2008 at 04:15:47PM +0100, Jim Meyering wrote:
Daniel Veillard [EMAIL PROTECTED] 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 */
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] many more translatable strings need to be marked
Richard W.M. Jones [EMAIL PROTECTED] wrote: ... -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. I thought xgettext (or whatever it is which generates the .pot file) would combine equal strings? It does. And gcc reuses them, too. He's just saying it'd be good to avoid all this duplication in the .c file: which is true, of course: $ git grep 'remoteDis.*domain.not.found'|sort|uniq -c 29 qemud/remote.c:remoteDispatchError (client, req, %s, _(domain not found)); $ git grep 'remoteDis.*network.not.found'|wc -l 7 $ git grep 'remoteDis.*storage_pool.not.found'|wc -l 14 But it's independent of whether to translate the strings. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] many more translatable strings need to be marked
Daniel Veillard [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 04:54:38PM +0100, Jim Meyering wrote: Daniel Veillard [EMAIL PROTECTED] wrote: 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 */ Hum, how that comment for the transaltors actually shows up in their tools ? xgettext copies comments marked with TRANSLATORS: to the *.po files. Honnestly I would rather avoid aving the string sent to them if we know they can't do anything. Sure, we'd rather have good diagnostics everywhere, and still be able to automatically check for unmarked diagnostics. I've proposed a compromise that lets us defer the tedious (and low-priority, imho) work of improving diagnostics that are unlikely to be seen. If that is unsatisfactory, can you propose something else? -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [Libvir] many more translatable strings need to be marked
On Fri, Feb 29, 2008 at 04:54:38PM +0100, Jim Meyering wrote: Daniel Veillard [EMAIL PROTECTED] wrote: 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 */ Hum, how that comment for the transaltors actually shows up in their tools ? Honnestly I would rather avoid aving the string sent to them if we know they can't do anything. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
