2012/5/2 Ralf Thielow <ralf.thielow@xxxxxxxxxxxxxx>:
> #: 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("<color header>ahead</color> <color
local>%d</color>, <color header>behind</color> <color
local>%d/<color>", ...);
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.
--
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