Re: [PATCH on ab/i18n] branch: remove lego in i18n tracking info strings

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH on ab/i18n] branch: remove lego in i18n tracking info strings

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:53:44

Nguyễn Thái Ngọc Duy [off-list ref] writes:
Pseudo html tags to to mark color, like
 "On branch <color1>%s</color1>" is probably not a bad idea.
The output machinery needs to understand _some_ color mark-up if the
destination does not support ANSI colors natively, and there already is
such a code in compat/ for windows IIRC.  Adding yet another color mark-up
wouldn't help anybody.  I would suggest to just declare that internally we
use ANSI colors as the standard color mark-up and be done with it.
quoted hunk
 builtin/branch.c |   31 ++++++++++++++++++++++---------
 1 files changed, 22 insertions(+), 9 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 8813d2e..5011881 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -384,6 +384,7 @@ static void fill_tracking_info(struct strbuf *stat, const char *branch_name,
 		int show_upstream_ref)
 {
 	int ours, theirs;
+	const char *ref = NULL;
 	struct branch *branch = branch_get(branch_name);
 
 	if (!stat_tracking_info(branch, &ours, &theirs)) {
@@ -394,16 +395,28 @@ static void fill_tracking_info(struct strbuf *stat, const char *branch_name,
 		return;
 	}
 
-	strbuf_addch(stat, '[');
 	if (show_upstream_ref)
-		strbuf_addf(stat, "%s: ",
-			shorten_unambiguous_ref(branch->merge[0]->dst, 0));
-	if (!ours)
-		strbuf_addf(stat, _("behind %d] "), theirs);
-	else if (!theirs)
-		strbuf_addf(stat, _("ahead %d] "), ours);
-	else
-		strbuf_addf(stat, _("ahead %d, behind %d] "), ours, theirs);
+		ref = shorten_unambiguous_ref(branch->merge[0]->dst, 0);
+	if (!ours) {
+		if (ref)
+			strbuf_addf(stat, _("[%s: behind %d]"), ref, theirs);
+		else
+			strbuf_addf(stat, _("[behind %d]"), theirs);
+
+	} else if (!theirs) {
+		if (ref)
+			strbuf_addf(stat, _("[%s: ahead %d]"), ref, ours);
+		else
+			strbuf_addf(stat, _("[ahead %d]"), ours);
+	} else {
+		if (ref)
+			strbuf_addf(stat, _("[%s: ahead %d, behind %d]"),
+				    ref, ours, theirs);
+		else
+			strbuf_addf(stat, _("[ahead %d, behind %d]"),
+				    ours, theirs);
+	}
+	strbuf_addch(stat, ' ');
You should free "ref" here, as it is an allocated piece of memory you own.

Re: [PATCH on ab/i18n] branch: remove lego in i18n tracking info strings

From: Nguyen Thai Ngoc Duy <hidden>
Date: 2016-06-15 22:53:45

On Fri, May 4, 2012 at 11:10 PM, Junio C Hamano [off-list ref] wrote:
Nguyễn Thái Ngọc Duy [off-list ref] writes:
quoted
Pseudo html tags to to mark color, like
 "On branch <color1>%s</color1>" is probably not a bad idea.
The output machinery needs to understand _some_ color mark-up if the
destination does not support ANSI colors natively, and there already is
such a code in compat/ for windows IIRC.  Adding yet another color mark-up
wouldn't help anybody.  I would suggest to just declare that internally we
use ANSI colors as the standard color mark-up and be done with it.
Ævar started a new thread about this and I elaborated a little bit
there [1]. We cannot just put straight ANSI colors in the string
because they are customizable. We don't know what color to put in the
string at compile time. So we need an intermediate color
representation for translators anyway to avoid fragmented strings. The
problem is which way is better, "On branch %s%s%s", "On branch
<color>%s</color>" or some other ways

[1] http://thread.gmane.org/gmane.comp.version-control.git/196869/focus=196908
-- 
Duy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help