git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Breaking up Git's color emission for i18n

From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date
May 3, 2012, 13:35 UTC
Message-ID
<CACsJy8DO6OqjowV32V9S2ehaXHLD+F1UdCmE_JBY3wyM5RasKw@mail.gmail.com>
In-Reply-To
<CACBZZX7fE0CT5xV+QKPZ4BnkqdU0Lmd8LQU+45kjt+RM0meuEA@mail.gmail.com>

On Thu, May 3, 2012 at 5:56 AM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 15 quoted lines
> 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>", ...);

I am thinking of something more like "<color>ahead</color> <ours>%d</ours>, <color>behind</color> <theirs>%d</theirs>". 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, "<color>ahead</color> <ours>%d</ours>, <color>behind</color> <theirs>%d</theirs>", ours, theirs);

It'd be even more great if strbuf_substitute_tags() can flatten nested tags, so "<foo>abc<bar>def</bar>ghi</foo>" becomes "<foo>abc</foo><bar>def</bar><foo>ghi</foo>".

The drawback is msgfmt does not catch malformed tags. But that already happens for plenty other projects. Maybe msgfmt will learn that soon.

Show 27 quoted lines
> 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
Previous: Ævar Arnfjörð Bjarmason
Message 2 of 2 in “Breaking up Git's color emission for i18n”
  1. Ævar Arnfjörð BjarmasonMay 2, 2012
  2. Nguyen Thai Ngoc DuyMay 3, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.