| Message ID | 8f2c08474a75793c24af7d4ae44d73d2b23920bc.1610441263.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Introduce support for GETTEXT_POISON=rot13 | expand |
On Tue, Jan 12, 2021 at 08:47:35AM +0000, Johannes Schindelin via GitGitGadget wrote: > diff --git a/sha1dc_git.c b/sha1dc_git.c > index 5c300e812e0..fecf5da1483 100644 > --- a/sha1dc_git.c > +++ b/sha1dc_git.c > @@ -18,7 +18,7 @@ void git_SHA1DCFinal(unsigned char hash[20], SHA1_CTX *ctx) > { > if (!SHA1DCFinal(hash, ctx)) > return; > - die("SHA-1 appears to be part of a collision attack: %s", > + die(_("SHA-1 appears to be part of a collision attack: %s"), > hash_to_hex_algop(hash, &hash_algos[GIT_HASH_SHA1])); I didn't find any list discussion, but I think I may have actually left this untranslated intentionally. Like a BUG(), we'd expect it to come up basically never. And when it does, being able to search for the exact wording online may be more important than providing a translated version. It probably doesn't matter that much either way, though. -Peff
Jeff King <peff@peff.net> writes: > On Tue, Jan 12, 2021 at 08:47:35AM +0000, Johannes Schindelin via GitGitGadget wrote: > >> diff --git a/sha1dc_git.c b/sha1dc_git.c >> index 5c300e812e0..fecf5da1483 100644 >> --- a/sha1dc_git.c >> +++ b/sha1dc_git.c >> @@ -18,7 +18,7 @@ void git_SHA1DCFinal(unsigned char hash[20], SHA1_CTX *ctx) >> { >> if (!SHA1DCFinal(hash, ctx)) >> return; >> - die("SHA-1 appears to be part of a collision attack: %s", >> + die(_("SHA-1 appears to be part of a collision attack: %s"), >> hash_to_hex_algop(hash, &hash_algos[GIT_HASH_SHA1])); > > I didn't find any list discussion, but I think I may have actually left > this untranslated intentionally. Like a BUG(), we'd expect it to come up > basically never. And when it does, being able to search for the exact > wording online may be more important than providing a translated > version. > > It probably doesn't matter that much either way, though. I can believe if this was intentionally left untranslated for the reasons you stated. Without introducing "message ID" that can be universally readable, so that customers can report "We got E42234 when running Git version 1.2.3.4", that is the best we could do. But I am OK to see this translated, too. Thanks.
Hi Peff, On Tue, 12 Jan 2021, Jeff King wrote: > On Tue, Jan 12, 2021 at 08:47:35AM +0000, Johannes Schindelin via GitGitGadget wrote: > > > diff --git a/sha1dc_git.c b/sha1dc_git.c > > index 5c300e812e0..fecf5da1483 100644 > > --- a/sha1dc_git.c > > +++ b/sha1dc_git.c > > @@ -18,7 +18,7 @@ void git_SHA1DCFinal(unsigned char hash[20], SHA1_CTX *ctx) > > { > > if (!SHA1DCFinal(hash, ctx)) > > return; > > - die("SHA-1 appears to be part of a collision attack: %s", > > + die(_("SHA-1 appears to be part of a collision attack: %s"), > > hash_to_hex_algop(hash, &hash_algos[GIT_HASH_SHA1])); > > I didn't find any list discussion, but I think I may have actually left > this untranslated intentionally. Like a BUG(), we'd expect it to come up > basically never. And when it does, being able to search for the exact > wording online may be more important than providing a translated > version. I disagree with that reasoning. By that rationale, any message we deem to be somewhat rare should be _untranslated_. A much better rule, at least from my perspective is: is the target audience the Git users? If so, the message is to be translated. If not, then not. In this instance, it is quite obviously targeting the Git users who need to understand why the command they tried to run was failing. The test in t0013 is totally agreeing with this: test_expect_success 'test-sha1 detects shattered pdf' ' test_must_fail test-tool sha1 <"$TEST_DATA/shattered-1.pdf" 2>err && test_i18ngrep collision err && grep 38762cf7f55934b34d179ae6a4c80cadccbb7f0a err ' Notice that `test_i18ngrep`? It tells me that we expect this message to be translated. Ciao, Dscho
On Fri, Jan 15, 2021 at 04:43:05PM +0100, Johannes Schindelin wrote: > > > - die("SHA-1 appears to be part of a collision attack: %s", > > > + die(_("SHA-1 appears to be part of a collision attack: %s"), > > > hash_to_hex_algop(hash, &hash_algos[GIT_HASH_SHA1])); > > > > I didn't find any list discussion, but I think I may have actually left > > this untranslated intentionally. Like a BUG(), we'd expect it to come up > > basically never. And when it does, being able to search for the exact > > wording online may be more important than providing a translated > > version. > > I disagree with that reasoning. By that rationale, any message we deem to > be somewhat rare should be _untranslated_. > > A much better rule, at least from my perspective is: is the target > audience the Git users? If so, the message is to be translated. If not, > then not. That's what I was getting at. The audience is really Git developers, just like it would be for a BUG(). We don't expect either of those things to happen. > In this instance, it is quite obviously targeting the Git users who need > to understand why the command they tried to run was failing. The test in > t0013 is totally agreeing with this: > > test_expect_success 'test-sha1 detects shattered pdf' ' > test_must_fail test-tool sha1 <"$TEST_DATA/shattered-1.pdf" 2>err && > test_i18ngrep collision err && > grep 38762cf7f55934b34d179ae6a4c80cadccbb7f0a err > ' > > Notice that `test_i18ngrep`? It tells me that we expect this message to be > translated. Well, I wrote both that line and the untranslated original code, so I'm not sure what we can deduce from that. ;) But yeah, I am not strongly opposed to translating this. I brought it up more in the line of "I don't think it's that big a deal that it was not translated". -Peff
Hi Peff, On Fri, 15 Jan 2021, Jeff King wrote: > On Fri, Jan 15, 2021 at 04:43:05PM +0100, Johannes Schindelin wrote: > > > > > - die("SHA-1 appears to be part of a collision attack: %s", > > > > + die(_("SHA-1 appears to be part of a collision attack: %s"), > > > > hash_to_hex_algop(hash, &hash_algos[GIT_HASH_SHA1])); > > > > > > I didn't find any list discussion, but I think I may have actually left > > > this untranslated intentionally. Like a BUG(), we'd expect it to come up > > > basically never. And when it does, being able to search for the exact > > > wording online may be more important than providing a translated > > > version. > > > > I disagree with that reasoning. By that rationale, any message we deem to > > be somewhat rare should be _untranslated_. > > > > A much better rule, at least from my perspective is: is the target > > audience the Git users? If so, the message is to be translated. If not, > > then not. > > That's what I was getting at. The audience is really Git developers, > just like it would be for a BUG(). We don't expect either of those > things to happen. While a SHA-1 collision might not be anything we expect to happen, I am fairly certain it won't be a bug in Git causing it. Nor will it be anything that core Git developers have to react on. For those reasons, I disagree that core Git developers are the target audience of this message. Ciao, Dscho
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: >> That's what I was getting at. The audience is really Git developers, >> just like it would be for a BUG(). We don't expect either of those >> things to happen. > > While a SHA-1 collision might not be anything we expect to happen, I am > fairly certain it won't be a bug in Git causing it. Nor will it be > anything that core Git developers have to react on. For those reasons, I > disagree that core Git developers are the target audience of this message. I do not know if this is what Peff meant by "the audience is really Git developers", but when any end-user encounters this message, we want to learn about it a lot more urgently than all the ordinary "there is no such command line option", so in that sense, even it is not "a bug in git", it is more special than ordinary errors.
Hi Junio, On Mon, 18 Jan 2021, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > >> That's what I was getting at. The audience is really Git developers, > >> just like it would be for a BUG(). We don't expect either of those > >> things to happen. > > > > While a SHA-1 collision might not be anything we expect to happen, I am > > fairly certain it won't be a bug in Git causing it. Nor will it be > > anything that core Git developers have to react on. For those reasons, I > > disagree that core Git developers are the target audience of this message. > > I do not know if this is what Peff meant by "the audience is really > Git developers", but when any end-user encounters this message, we > want to learn about it a lot more urgently than all the ordinary > "there is no such command line option", so in that sense, even it > is not "a bug in git", it is more special than ordinary errors. I suggest that we modify the message to state exactly that: "Please contact the Git mailing list at git@vger.kernel.org about this". And then mark the message for translation, so that even Git users with low/no knowledge of the English language are in a position to help us. Ciao, Dscho P.S.: Yes, I realize that this means we could receive a message reporting a SHA-1 collision written in, say, Chinese. Is this a problem? I don't think so. In any case, this would still be much better than keeping the message untranslated and _not_ receiving a mail about it.
diff --git a/sha1dc_git.c b/sha1dc_git.c index 5c300e812e0..fecf5da1483 100644 --- a/sha1dc_git.c +++ b/sha1dc_git.c @@ -18,7 +18,7 @@ void git_SHA1DCFinal(unsigned char hash[20], SHA1_CTX *ctx) { if (!SHA1DCFinal(hash, ctx)) return; - die("SHA-1 appears to be part of a collision attack: %s", + die(_("SHA-1 appears to be part of a collision attack: %s"), hash_to_hex_algop(hash, &hash_algos[GIT_HASH_SHA1])); }