Hi,
Alangi Derick wrote:
> [To: unlisted-recipients: no To-header on input <;]
Please don't do that.
What mailer do you use to send patches? Others on the list using the
same mailer might be able to help with configuration tips.
> [Subject: [PATCH] Fixed a translation error]
The above commit description is vague and confusing: in fact, this
patch doesn't fix a translation error. Instead, the commit
description should explain the purpose of the change in such a way as
to make it clear why a person might want to apply it.
More details are in Documentation/SubmittingPatches.
> Signed-off-by: Alangi Derick <alangiderick@xxxxxxxxx>
Thanks.
[...]
> +++ b/builtin/config.c
Yes, this is an okay command to start with. Some messages are already
translated in this file, so it's a good example of a command that
currently presents an inconsistent interface in some languages.
[...]
> @@ -412,7 +412,7 @@ static int get_urlmatch(const char *var, const char *url)
> config.cb = &values;
>
> if (!url_normalize(url, &config.url))
> - die("%s", config.url.err);
> + die(_("%s"), config.url.err);
This change is subtle. It lets a translator replace the format "%s"
with something else --- that wouldn't be useful in any language, so
this string should not be marked for translation.
The underlying message in config.url.err is from urlmatch.c and is
already translated.
There are two more strings that need to be marked for translation in
this file: "Invalid key pattern: %s" and "Invalid pattern: %s".
Here's a preparatory patch to make that output more consistent.
One more piece of advice: when working on many similar patches like
this, a good strategy is to just send out one and get review for it.
When it has been reviewed and is in good shape, you can move on to
preparing and polishing the next patch. The first few reviewed
patches can be used a template for the rest.
In other words, only once it's very clear that all the patches are
likely to be in good shape is it time to prepare and send out all of
them. By working through only one patch at a time in a collection of
similar, unfinished patches, you avoid wasting time re-writing all the
patches in response to feedback and avoid overwhelming reviewers by
asking them to keep track of many reviews at once. Most comments on
one patch will also apply to all the rest and the conversation only
has to happen once.
Thanks,
Jonathan
-- >8 --
Subject: config: use error() instead of fprintf(stderr, ...)
The die() / error() / warning() helpers put a fatal: / error: /
warning: prefix in front of the error message they print describing
the message's severity, which users are likely to be accustomed to
seeing these days.
This change will also be useful when marking the message for
translation: the argument to error() includes no newline at the end,
so it is less fussy for translators to translate without lines running
together in the translated output.
While we're here, start the error messages with a lowercase letter to
match the usual typography of error messages.
A quick web search and a code search at codesearch.debian.net finds no
scripts trying to parse these error messages, so this change should be
safe.
Signed-off-by: Jonathan Nieder <jrnieder@xxxxxxxxx>
---
builtin/config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index d32c532..89f3208 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -193,7 +193,7 @@ static int get_value(const char *key_, const char *regex_)
key_regexp = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(key_regexp, key, REG_EXTENDED)) {
- fprintf(stderr, "Invalid key pattern: %s\n", key_);
+ error("invalid key pattern: %s", key_);
free(key_regexp);
key_regexp = NULL;
ret = CONFIG_INVALID_PATTERN;
@@ -214,7 +214,7 @@ static int get_value(const char *key_, const char *regex_)
regexp = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(regexp, regex_, REG_EXTENDED)) {
- fprintf(stderr, "Invalid pattern: %s\n", regex_);
+ error("invalid pattern: %s", regex_);
free(regexp);
regexp = NULL;
ret = CONFIG_INVALID_PATTERN;
--
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html