From: Nguyen Thai Ngoc Duy Date: Thu, 03 May 2012 13:35:16 GMT Subject: Re: Breaking up Git's color emission for i18n Message-ID: In-Reply-To: On Thu, May 3, 2012 at 5:56 AM, Ævar Arnfjörð Bjarmason wrote: > Whether that's the case or not I wonder how we could handle all these > lego translations in wt-status.c. > > Currently we have stuff like this: > >    color_fprintf(s->fp, header_color, _("ahead ")); >    color_fprintf(s->fp, branch_color_local, "%d", num_ours); >    color_fprintf(s->fp, header_color, _(", behind ")); >    color_fprintf(s->fp, branch_color_remote, "%d", num_theirs); > > That could be something clever like this: > >    color_fprintf("ahead local>%d, behind local>%d/", ...); I am thinking of something more like "ahead %d, behind %d". It gives more context to translators. Then we could do a simple search/replace: struct tag_subst colors[] = { { "color", WT_STATUS_HEADER, GIT_COLOR_RESET }, { "ours", WT_STATUS_LOCAL_BRANCH, GIT_COLOR_RESET }, { "theirs", WT_STATUS_REMOTE_BRANCH, GIT_COLOR_RESET }, { NULL, NULL, NULL } }; strbuf_substitute_tags(buf, colors, "ahead %d, behind %d", ours, theirs); It'd be even more great if strbuf_substitute_tags() can flatten nested tags, so "abcdefghi" becomes "abcdefghi". The drawback is msgfmt does not catch malformed tags. But that already happens for plenty other projects. Maybe msgfmt will learn that soon. > We have some code in color_parse() in color.c for parsing colors, but > I haven't spotted if it can parse embedded things like that. > > But I think an easier option is: > >    color_fprintf(%sahead%s %s%d%s, %sbehind%s %s%d%s", >                  header_color_begin, >                  color_reset, >                  branch_color_begin, >                  num_ours, >                  color_reset, >                  ... >    ); > > Which we already use in e.g. branch.c: > >    strbuf_addf(&out, "%c %s%-*s%s", c, branch_get_color(color), >            maxwidth, name.buf, >            branch_get_color(BRANCH_COLOR_RESET)); > > That would result in lots of arguments and fairly unintelligible > format strings, but at least we wouldn't have to create some custom > parser and the msgfmt --check option would check that we have all the > formats there. > > We could also expose this as an internal command to do coloring for > our shellscript libraries. -- Duy