Johannes Schindelin [off-list ref] writes:
On Tue, 12 Jan 2021, Junio C Hamano wrote:
quoted
quoted
+static size_t unrot13(char *buf)
+{
+ char *p = buf, *q = buf;
+
+ while (*p) {
+ const char *begin = strstr(p, "<rot13>"), *end;
AFAIR from my reading of [02/11], the encoding side did not special
case the payload that has <ebg13> or </ebg13>; if we want to make it
reversible conversion (which is excellent improvement over the
current "# GETTEXT_POISON #" obfuscation), we'd need to do something
about it, I think.
Do you expect any message to be translated _twice_?
Not at all.
But what I had in mind, when I wrote the above, was that the
programmers are entitled to expect that they are allowed to say:
die(_("message with <ebg13/>, <ebg13> and <rot13> in it"));
This will be rot13'd, and the entire thing will be enclosed inside
"<rot13>...</rot13>"; I would expect that somewhere inside "..." the
receiving end that attempts to parse it by relying on these markers
will be confused.
quoted
But on second thought, nobody can prevent a caller to die(_("%s", msg));
to have "<rot13>" in the msg part, so perhaps punting like this
series does is sufficient. I dunno.
And this comment still stands.
Hi Junio,
On Fri, 15 Jan 2021, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Tue, 12 Jan 2021, Junio C Hamano wrote:
quoted
quoted
+static size_t unrot13(char *buf)
+{
+ char *p = buf, *q = buf;
+
+ while (*p) {
+ const char *begin = strstr(p, "<rot13>"), *end;
AFAIR from my reading of [02/11], the encoding side did not special
case the payload that has <ebg13> or </ebg13>; if we want to make it
reversible conversion (which is excellent improvement over the
current "# GETTEXT_POISON #" obfuscation), we'd need to do something
about it, I think.
Do you expect any message to be translated _twice_?
Not at all.
But what I had in mind, when I wrote the above, was that the
programmers are entitled to expect that they are allowed to say:
die(_("message with <ebg13/>, <ebg13> and <rot13> in it"));
This will be rot13'd, and the entire thing will be enclosed inside
"<rot13>...</rot13>"; I would expect that somewhere inside "..." the
receiving end that attempts to parse it by relying on these markers
will be confused.
Oh, _that_ is what you meant.
Yep, I don't expect any of Git's messages to contain "<ebg13>", ever.
quoted
quoted
But on second thought, nobody can prevent a caller to die(_("%s", msg));
to have "<rot13>" in the msg part, so perhaps punting like this
series does is sufficient. I dunno.
And this comment still stands.
Slightly pedantic: the call would be `die(_("%s"), msg)` (note that the
`msg` is not inside the `_(...)`).
Similar to my point above, I do not expect any of Git's tests to emit a
message like that, and certainly not once/if we turn on rot13 mode in the
GETTEXT_POISON job of the CI build.
A blocker would have been if there might be the possibility that we _must_
add a test in the future that wants to emit a `msg` containing `<rot13>`.
But that seems utterly unlikely. And even if: then we'd just change the
rot13 mode to use a different needle.
Ciao,
Dscho