# Breaking up Git's color emission for i18n

2 messages from 2012-05-02 to 2012-05-03. Participants: Ævar Arnfjörð Bjarmason, Nguyen Thai Ngoc Duy.
Thread: https://gitlist.dev/t/30401

## Ævar Arnfjörð Bjarmason, 2012-05-02 22:56

Subject: Breaking up Git's color emission for i18n
Message-ID: <CACBZZX7fE0CT5xV+QKPZ4BnkqdU0Lmd8LQU+45kjt+RM0meuEA@mail.gmail.com>
URL: https://gitlist.dev/e/CACBZZX7fE0CT5xV%2BQKPZ4BnkqdU0Lmd8LQU%2B45kjt%2BRM0meuEA%40mail.gmail.com

```
2012/5/2 Ralf Thielow <ralf.thielow@googlemail.com>:
>  #: 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.

```

## Nguyen Thai Ngoc Duy, 2012-05-03 13:35

Subject: Re: Breaking up Git's color emission for i18n
Message-ID: <CACsJy8DO6OqjowV32V9S2ehaXHLD+F1UdCmE_JBY3wyM5RasKw@mail.gmail.com>
URL: https://gitlist.dev/e/CACsJy8DO6OqjowV32V9S2ehaXHLD%2BF1UdCmE_JBY3wyM5RasKw%40mail.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:
> 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.

> 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

```