Re: [PATCH 00/11] [RFH] Introduce support for GETTEXT_POISON=rot13

2 messages, 2 authors, 2021-01-13 · open the first message on its own page

Re: [PATCH 00/11] [RFH] Introduce support for GETTEXT_POISON=rot13

From: Junio C Hamano <hidden>
Date: 2021-01-12 19:51:55

Jeff King [off-list ref] writes:
Likewise, I'm not sure that one can reliably rot13 an output for
test_i18ncmp. It could contain mixed translated and untranslated bits
from different messages.
As long as <rot13>...</rot13> marking can be trusted (and it cannot
be, but if we declare it is OK to punt, then by definition we can),
I think the messages can be compared.
So I dunno. You did find two spots where translations could be used.
But if nobody actually saw them to care that they got translated, were
they important? I may be a bit biased as somebody who would not use the
translations in the first place, of course.
I viewed the series with interest, mostly (i.e. 80%+) for its "fun
value"; I tend to agree with you that I doubt its usefulness.

Re: [PATCH 00/11] [RFH] Introduce support for GETTEXT_POISON=rot13

From: Jeff King <hidden>
Date: 2021-01-13 07:33:14

On Tue, Jan 12, 2021 at 11:50:52AM -0800, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
Likewise, I'm not sure that one can reliably rot13 an output for
test_i18ncmp. It could contain mixed translated and untranslated bits
from different messages.
As long as <rot13>...</rot13> marking can be trusted (and it cannot
be, but if we declare it is OK to punt, then by definition we can),
I think the messages can be compared.
Good point. I should have looked at the implementation more carefully
before responding (and I agree that while not foolproof, tagging like
that would work OK in practice).

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help