Re: [PATCH v4 27/73] gettextize: git-commit formatting messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jonathan Nieder <jrnieder@xxxxxxxxx> writes:

> diff --git a/t/lib-commit-template.sh b/t/lib-commit-template.sh
> new file mode 100644
> index 0000000..80ec50c
> --- /dev/null
> +++ b/t/lib-commit-template.sh
> @@ -0,0 +1,19 @@
> +#!/bin/sh
> +
> +# Messages such as
> +#
> +#      # It looks like you may be committing a MERGE.\n"
> +#
> +# are now translatable, even though the "# " part probably ought not
> +# to be.  Expect some tests to fail when GETTEXT_POISON is enabled.

We shouldn't mark "# " part as translatable to begin with.  Perhaps the
underlying code in wt-status.c needs to be changed even before we merge
the i18n _() patches to make it easier?

It might be a good idea to introduce status_print{,_ln,_more} wrapper
functions around color_vfprintf(), and change the existing callers to look
like this:

                const char *c = color(WT_STATUS_HEADER, s);

        -       color_fprintf_ln(s->fp, c, "# Unmerged paths:");
        +       status_printf_ln(s, c, "Unmerged paths:");
                if (!advice_status_hints)
                        return;
                if (s->in_merge)
                        ;
        ...

        -       color_fprintf(s->fp, color(WT_STATUS_HEADER, s), "#\t");
        +       status_printf(s, color(WT_STATUS_HEADER, s), "\t");
                switch (status) {
                case DIFF_STATUS_ADDED:
        -               color_fprintf(s->fp, c, "new file:   %s", one);
        +               status_printf_more(s, c, "new file:   %s", one);
                        break;

Possible semantics for the three wrappers are:

 * status_printf_ln() takes all the parameters necessary to produce a
   single line; it works just like color_fprintf_ln() but adds the "# "
   prefix itself.

 * status_printf_more() is just a synonym for color_fprintf_ln() in the
   above but is not necessary.

 * status_printf() would be like color_printf() but adds the "# " prefix
   itself.

I am Ok with naming "status-printf-more" to just "status-printf" and
renaming "status-printf" to "status-printf-bol", as long as we have two
functions, one that adds "# " and the other that does not.

The adding of "# " done by status_printf() and status_printf_ln() can and
probably should have a bit of twist to adjust to the _real_ contents that
are fed to them.

Ideally, status_printf_ln(s, color, "") should omit the trailing SP and
give "<COLOR>#</COLOR>\n", and status_printf(s, color, "\t") should should
give "<COLOR>#\t</COLOR>" to avoid SP-HT.

Doing this would have two advantages over the current code:

 - The obvious one is to force separation of the "#" from the translatable
   part of the message, which is the topic of this thread.

 - Another advantage is that this makes it easier for us to drop "#"
   prefix in "git status" output in later versions of git if we wanted to.

In "git commit" template, these lines need to be made into comments, but
there is no reason, other than that we are sooooo used to seeing these
lines prefixed with "# ", in "git status" output.
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]