From: Ævar Arnfjörð Bjarmason Date: Wed, 02 May 2012 22:56:24 GMT Subject: Breaking up Git's color emission for i18n Message-ID: 2012/5/2 Ralf Thielow : >  #: wt-status.c:905 >  msgid "behind " > -msgstr "hinter " > +msgstr "hinterher: " > >  #: wt-status.c:908 wt-status.c:911 >  msgid "ahead " > -msgstr "weiter: " > +msgstr "voraus: " Isn't this an artifact of you rather wanting to have: 3 hinterher, 2 voraus But because the code imposes the word order you're going for: hinterher: 3, voraus: 2 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 %d, behind %d/", ...); 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.