Thread (1 message) 1 message, 1 author, 2016-06-16

Re: [PATCH v3 13/16] ref-filter: allow porcelain to translate messages in the output

From: Junio C Hamano <hidden>
Date: 2016-06-16 02:18:39

Matthieu Moy [off-list ref] writes:
I'm not sure how important it is in this case, but it was in the case of
setup_unpack_trees_porcelain which I took inspiration from when we
discussed this (actually, in setup_unpack_trees_porcelain, there's isn't
any translation even in porcelain).
OK, so paraphrase:

In the most general case, we might want to have one code to issue
different messages between plumbing and Porcelain; further, for
Porcelain messages may or may not want to be translated.

But I suspect that all Porcelain messages should be translatable
in general, so there probably is a room for simplification.

The single macro P_() approach was done without knowing that this
codepath wanted the distinction between the plumbing and Porcelain.
Note that this can be worked around later by adding another function like

        static const char *get_message(const char *porcelain, const char *plumbing)
        {
                return use_porcelain_msg ? porcelain : plumbing;
        }

to be called with get_message(_("this ref was gone"), "gone") or so.
Yes, I think that would be a way to do this properly.  And we do not
have a separate "here is the list of all translatable messages"
table, which is a big plus.
In summary: both would work. No strong opinion from me, but I slightly
prefer the version in the patch (i.e. the one I suggested IIRC) to
Junio's version.
Yup.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help