(+cc: some fetch ui authors, just as a heads up)
Ævar Arnfjörð Bjarmason wrote:
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -236,7 +236,7 @@ static int update_local_ref(struct ref *ref,
> if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
> if (verbosity > 0)
> sprintf(display, "= %-*s %-*s -> %s", TRANSPORT_SUMMARY_WIDTH,
> - "[up to date]", REFCOL_WIDTH, remote,
> + _("[up to date]"), REFCOL_WIDTH, remote,
> pretty_ref);
Longer-term question: do people like to translate this kind of thing
(with the arrows and so on) differently for right-to-left languages or
is that considered overkill?
> @@ -249,8 +249,8 @@ static int update_local_ref(struct ref *ref,
> * If this is the head, and it's not okay to update
> * the head, and the old value of the head isn't empty...
> */
> - sprintf(display, "! %-*s %-*s -> %s (can't fetch in current branch)",
> - TRANSPORT_SUMMARY_WIDTH, "[rejected]", REFCOL_WIDTH, remote,
> + sprintf(display, _("! %-*s %-*s -> %s (can't fetch in current branch)"),
> + TRANSPORT_SUMMARY_WIDTH, _("[rejected]"), REFCOL_WIDTH, remote,
Regardless of the answer, we should probably be either consistently
translating or not translating it within this patch. e.g. for not
translating (though I suspect translating is the better choice):
sprintf(display, "! %-*s %-*s -> %s %s",
TRANSPORT_SUMMARY_WIDTH, "[rejected]", REFCOL_WIDTH, remote,
pretty_ref, _("(can't fetch in current branch)"));
> @@ -260,8 +260,8 @@ static int update_local_ref(struct ref *ref,
> int r;
> r = s_update_ref("updating tag", ref, 0);
> sprintf(display, "%c %-*s %-*s -> %s%s", r ? '!' : '-',
> - TRANSPORT_SUMMARY_WIDTH, "[tag update]", REFCOL_WIDTH, remote,
> - pretty_ref, r ? " (unable to update local ref)" : "");
> + TRANSPORT_SUMMARY_WIDTH, _("[tag update]"), REFCOL_WIDTH, remote,
> + pretty_ref, r ? _(" (unable to update local ref)") : "");
Maybe we could stick to "%c %-*s %-*s -> %s%s", to make consistent
translation easier.
--
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