From: Thomas Rast <trast@inf.ethz.ch>
To: Ralf Thielow <ralf.thielow@gmail.com>
Cc: <jk@jk.gs>, <stimming@tuhh.de>, <git@vger.kernel.org>,
Jeff King <peff@peff.net>
Subject: Re: [PATCH] l10n: de.po: translate 5 messages
Date: Wed, 7 Aug 2013 11:17:08 +0200 [thread overview]
Message-ID: <87r4e5vp0r.fsf@linux-k42r.v.cablecom.net> (raw)
In-Reply-To: <1375813794-4578-1-git-send-email-ralf.thielow@gmail.com> (Ralf Thielow's message of "Tue, 6 Aug 2013 20:29:54 +0200")
Ralf Thielow <ralf.thielow@gmail.com> writes:
>
The changes look good to me. The following is purely about the original
English messages.
> #: builtin/commit.c:62
> -#, fuzzy
> msgid ""
> "The previous cherry-pick is now empty, possibly due to conflict resolution.\n"
> "If you wish to commit it anyway, use:\n"
> "\n"
> " git commit --allow-empty\n"
> @@ -4014,25 +4012,30 @@ msgstr ""
> "Konfliktauflösung.\n"
> "Wenn Sie dies trotzdem committen wollen, benutzen Sie:\n"
> "\n"
> " git commit --allow-empty\n"
> "\n"
> -"Andernfalls benutzen Sie bitte 'git reset'\n"
>
> #: builtin/commit.c:69
> msgid "Otherwise, please use 'git reset'\n"
> -msgstr ""
> +msgstr "Andernfalls benutzen Sie bitte 'git reset'\n"
This results from Peff's c17592a (commit: tweak empty cherry pick advice
for sequencer, 2013-07-26):
diff --git a/builtin/commit.c b/builtin/commit.c
index a17a5df..39717d5 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -62,8 +62,18 @@
"If you wish to commit it anyway, use:\n"
"\n"
" git commit --allow-empty\n"
+"\n");
+
+static const char empty_cherry_pick_advice_single[] =
+N_("Otherwise, please use 'git reset'\n");
+
+static const char empty_cherry_pick_advice_multi[] =
+N_("If you wish to skip this commit, use:\n"
"\n"
-"Otherwise, please use 'git reset'\n");
+" git reset\n"
+"\n"
+"Then \"git cherry-pick --continue\" will resume cherry-picking\n"
+"the remaining commits.\n");
static const char *use_message_buffer;
static const char commit_editmsg[] = "COMMIT_EDITMSG";
I was wondering for a while if this was a smart move, based on the usual
observation that it is better to translate things in one chunk because
many languages have more interdependencies than English does. The
gettext manual says:
puts ("Apollo 13 scenario: Stack overflow handling failed.");
puts ("On the next stack overflow we will crash!!!");
Should these two statements merged into a single one? I would recommend
to merge them if the two sentences are related to each other, because
then it makes it easier for the translator to understand and translate
both. On the other hand, if one of the two messages is a stereotypic
one, occurring in other places as well, you will do a favour to the
translator by not merging the two.
[...]
Translatable strings should be limited to one paragraph; don't let a
single message be longer than ten lines.
So it seems that concatenating sentences indeed falls into a gray area
between "avoid sentence lego" and "split at paragraphs". And Peff's
style of splitting it saves the translators work because the first part
of the message is shared among two code paths.
--
Thomas Rast
trast@{inf,student}.ethz.ch
next prev parent reply other threads:[~2013-08-07 9:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-06 18:29 [PATCH] l10n: de.po: translate 5 messages Ralf Thielow
2013-08-07 9:17 ` Thomas Rast [this message]
2013-08-07 9:22 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r4e5vp0r.fsf@linux-k42r.v.cablecom.net \
--to=trast@inf.ethz.ch \
--cc=git@vger.kernel.org \
--cc=jk@jk.gs \
--cc=peff@peff.net \
--cc=ralf.thielow@gmail.com \
--cc=stimming@tuhh.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.