{"thread":{"id":"30401","subject":"Breaking up Git's color emission for i18n","startedAt":"2012-05-02T22:56:24Z","lastAt":"2012-05-03T13:35:16Z","messageCount":2,"participants":["Ævar Arnfjörð Bjarmason","Nguyen Thai Ngoc Duy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"190604","messageId":"CACBZZX7fE0CT5xV+QKPZ4BnkqdU0Lmd8LQU+45kjt+RM0meuEA@mail.gmail.com","threadId":"30401","inReplyTo":null,"subject":"Breaking up Git's color emission for i18n","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2012-05-02T22:56:24Z","receivedAt":"2012-05-02T22:56:24Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"2012/5/2 Ralf Thielow <ralf.thielow@googlemail.com>:\n>  #: wt-status.c:905\n>  msgid \"behind \"\n> -msgstr \"hinter \"\n> +msgstr \"hinterher: \"\n>\n>  #: wt-status.c:908 wt-status.c:911\n>  msgid \"ahead \"\n> -msgstr \"weiter: \"\n> +msgstr \"voraus: \"\n\nIsn't this an artifact of you rather wanting to have:\n\n    3 hinterher, 2 voraus\n\nBut because the code imposes the word order you're going for:\n\n    hinterher: 3, voraus: 2\n\nWhether that's the case or not I wonder how we could handle all these\nlego translations in wt-status.c.\n\nCurrently we have stuff like this:\n\n    color_fprintf(s->fp, header_color, _(\"ahead \"));\n    color_fprintf(s->fp, branch_color_local, \"%d\", num_ours);\n    color_fprintf(s->fp, header_color, _(\", behind \"));\n    color_fprintf(s->fp, branch_color_remote, \"%d\", num_theirs);\n\nThat could be something clever like this:\n\n    color_fprintf(\"<color header>ahead</color> <color\nlocal>%d</color>, <color header>behind</color> <color\nlocal>%d/<color>\", ...);\n\nWe have some code in color_parse() in color.c for parsing colors, but\nI haven't spotted if it can parse embedded things like that.\n\nBut I think an easier option is:\n\n    color_fprintf(%sahead%s %s%d%s, %sbehind%s %s%d%s\",\n                  header_color_begin,\n                  color_reset,\n                  branch_color_begin,\n                  num_ours,\n                  color_reset,\n                  ...\n    );\n\nWhich we already use in e.g. branch.c:\n\n    strbuf_addf(&out, \"%c %s%-*s%s\", c, branch_get_color(color),\n            maxwidth, name.buf,\n            branch_get_color(BRANCH_COLOR_RESET));\n\nThat would result in lots of arguments and fairly unintelligible\nformat strings, but at least we wouldn't have to create some custom\nparser and the msgfmt --check option would check that we have all the\nformats there.\n\nWe could also expose this as an internal command to do coloring for\nour shellscript libraries.\n"},{"id":"190642","messageId":"CACsJy8DO6OqjowV32V9S2ehaXHLD+F1UdCmE_JBY3wyM5RasKw@mail.gmail.com","threadId":"30401","inReplyTo":"CACBZZX7fE0CT5xV+QKPZ4BnkqdU0Lmd8LQU+45kjt+RM0meuEA@mail.gmail.com","subject":"Re: Breaking up Git's color emission for i18n","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-05-03T13:35:16Z","receivedAt":"2012-05-03T13:35:16Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, May 3, 2012 at 5:56 AM, Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> Whether that's the case or not I wonder how we could handle all these\n> lego translations in wt-status.c.\n>\n> Currently we have stuff like this:\n>\n>    color_fprintf(s->fp, header_color, _(\"ahead \"));\n>    color_fprintf(s->fp, branch_color_local, \"%d\", num_ours);\n>    color_fprintf(s->fp, header_color, _(\", behind \"));\n>    color_fprintf(s->fp, branch_color_remote, \"%d\", num_theirs);\n>\n> That could be something clever like this:\n>\n>    color_fprintf(\"<color header>ahead</color> <color\n> local>%d</color>, <color header>behind</color> <color\n> local>%d/<color>\", ...);\n\nI am thinking of something more like \"<color>ahead</color>\n<ours>%d</ours>, <color>behind</color> <theirs>%d</theirs>\". It gives\nmore context to translators.\n\nThen we could do a simple search/replace:\n\nstruct tag_subst colors[] = {\n    { \"color\", WT_STATUS_HEADER, GIT_COLOR_RESET },\n    { \"ours\", WT_STATUS_LOCAL_BRANCH, GIT_COLOR_RESET },\n    { \"theirs\", WT_STATUS_REMOTE_BRANCH, GIT_COLOR_RESET },\n    { NULL, NULL, NULL }\n};\n\nstrbuf_substitute_tags(buf, colors, \"<color>ahead</color>\n<ours>%d</ours>, <color>behind</color> <theirs>%d</theirs>\", ours,\ntheirs);\n\nIt'd be even more great if strbuf_substitute_tags() can flatten nested\ntags, so \"<foo>abc<bar>def</bar>ghi</foo>\" becomes\n\"<foo>abc</foo><bar>def</bar><foo>ghi</foo>\".\n\nThe drawback is msgfmt does not catch malformed tags. But that already\nhappens for plenty other projects. Maybe msgfmt will learn that soon.\n\n> We have some code in color_parse() in color.c for parsing colors, but\n> I haven't spotted if it can parse embedded things like that.\n>\n> But I think an easier option is:\n>\n>    color_fprintf(%sahead%s %s%d%s, %sbehind%s %s%d%s\",\n>                  header_color_begin,\n>                  color_reset,\n>                  branch_color_begin,\n>                  num_ours,\n>                  color_reset,\n>                  ...\n>    );\n>\n> Which we already use in e.g. branch.c:\n>\n>    strbuf_addf(&out, \"%c %s%-*s%s\", c, branch_get_color(color),\n>            maxwidth, name.buf,\n>            branch_get_color(BRANCH_COLOR_RESET));\n>\n> That would result in lots of arguments and fairly unintelligible\n> format strings, but at least we wouldn't have to create some custom\n> parser and the msgfmt --check option would check that we have all the\n> formats there.\n>\n> We could also expose this as an internal command to do coloring for\n> our shellscript libraries.\n-- \nDuy\n"}]}