diff mbox series

[v2] l10n: reformat some localized strings for v2.23.0

Message ID 20190803195907.3124-1-jn.avila@free.fr (mailing list archive)
State New, archived
Headers show
Series [v2] l10n: reformat some localized strings for v2.23.0 | expand

Commit Message

Jean-Noël AVILA Aug. 3, 2019, 7:59 p.m. UTC
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
---
 builtin/checkout.c |  2 +-
 builtin/fetch.c    | 15 +++++++++++----
 2 files changed, 12 insertions(+), 5 deletions(-)

Comments

Jeff King Aug. 3, 2019, 11:45 p.m. UTC | #1
On Sat, Aug 03, 2019 at 09:59:07PM +0200, Jean-Noël Avila wrote:

> Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
> ---
>  builtin/checkout.c |  2 +-
>  builtin/fetch.c    | 15 +++++++++++----
>  2 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index 91f8509f85..08e19ed1ed 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -1769,7 +1769,7 @@ int cmd_restore(int argc, const char **argv, const char *prefix)
>  	struct option *options;
>  	struct option restore_options[] = {
>  		OPT_STRING('s', "source", &opts.from_treeish, "<tree-ish>",
> -			   N_("where the checkout from")),
> +			   N_("where the checkout is from")),

I think your original "where to checkout from" is better.

As a native speaker, "where the checkout is from" implies that checkout
is a noun that is being described. But I think we want checkout to be a
verb (because we are talking about the operation), and the option tells
Git how to do that operation.

(I agree the original "where the checkout from" is nonsense).

> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index 53ce99d2bb..0e8760e5d4 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -850,6 +850,15 @@ static int iterate_ref_map(void *cb_data, struct object_id *oid)
>  	return 0;
>  }
>  
> +static char warn_show_forced_updates[] =
> +N_("Fetch normally indicates which branches had a forced update, but that\n"
> +   "check has been disabled. To re-enable, use '--show-forced-updates' flag\n"
> +   "or run 'git config fetch.showForcedUpdates true'.");

This one isn't a typo fix, right? It's just putting the two warning()
calls into a single message. I can see how this would be useful for
translators, but note that the output will be different. The original
would be something like:

  warning: Fetch normally indicates...
  warning: To re-enable...

where now we'd get:

  warning: Fetch normally indicates...
  check has been disabled...
  or run 'git config...

which might be a bit harder to read because the wrapped lines lose the
prefix. For advise() we nicely pick out the newlines and prefix each
line individually, but warning(), error(), etc, don't do that. Maybe
they should.

That's too big for this late in the -rc cycle, I think. In the meantime,
I'm not sure which (the original or your patch) is the least-bad
solution. :)

This change (if I am right that there's no actual typo fix) should
perhaps be in a separate patch from the earlier hunk, though.

-Peff
Jean-Noël AVILA Aug. 4, 2019, 11:01 a.m. UTC | #2
On Sunday, 4 August 2019 01:45:22 CEST Jeff King wrote:
> On Sat, Aug 03, 2019 at 09:59:07PM +0200, Jean-Noël Avila wrote:
> 

> > -			   N_("where the checkout from")),
> > +			   N_("where the checkout is from")),
> 
> I think your original "where to checkout from" is better.
> 
> As a native speaker, "where the checkout is from" implies that checkout
> is a noun that is being described. But I think we want checkout to be a
> verb (because we are talking about the operation), and the option tells
> Git how to do that operation.
> 
> (I agree the original "where the checkout from" is nonsense).
> 


Oh. OK.

> > diff --git a/builtin/fetch.c b/builtin/fetch.c
> > index 53ce99d2bb..0e8760e5d4 100644
> > --- a/builtin/fetch.c
> > +++ b/builtin/fetch.c
> > @@ -850,6 +850,15 @@ static int iterate_ref_map(void *cb_data, struct object_id *oid)
> >  	return 0;
> >  }
> >  
> > +static char warn_show_forced_updates[] =
> > +N_("Fetch normally indicates which branches had a forced update, but that\n"
> > +   "check has been disabled. To re-enable, use '--show-forced-updates' flag\n"
> > +   "or run 'git config fetch.showForcedUpdates true'.");
> 
> This one isn't a typo fix, right? It's just putting the two warning()
> calls into a single message. I can see how this would be useful for
> translators, but note that the output will be different. The original
> would be something like:
> 
>   warning: Fetch normally indicates...
>   warning: To re-enable...
> 
> where now we'd get:
> 
>   warning: Fetch normally indicates...
>   check has been disabled...
>   or run 'git config...
> 
> which might be a bit harder to read because the wrapped lines lose the
> prefix. For advise() we nicely pick out the newlines and prefix each
> line individually, but warning(), error(), etc, don't do that. Maybe
> they should.
> 
> That's too big for this late in the -rc cycle, I think. In the meantime,
> I'm not sure which (the original or your patch) is the least-bad
> solution. :)
> 
> This change (if I am right that there's no actual typo fix) should
> perhaps be in a separate patch from the earlier hunk, though.
> 
> -Peff
> 

This one is not about typos.

My original fix was more concerning the second sequence, where the sentence is broken in the middle, simply for better rendering but this does not make sense either, because the lines are too long anyway.

I guess that in most languages, a sentence can be broken into two propositions by a coordinating conjunction, but it may not match the English structure.

Is it so important that the lines of warning all start with a "warning:" prefix?

JN
Jeff King Aug. 5, 2019, 4:21 a.m. UTC | #3
On Sun, Aug 04, 2019 at 01:01:51PM +0200, Jean-Noël AVILA wrote:

> This one is not about typos.
> 
> My original fix was more concerning the second sequence, where the
> sentence is broken in the middle, simply for better rendering but this
> does not make sense either, because the lines are too long anyway.

Ah, yeah, the sentence broken over the line is pretty bad for
translation. And I agree the lines are overly long.

> Is it so important that the lines of warning all start with a
> "warning:" prefix?

For some definition of "so". ;) As I said, I think your patch may be the
lesser of two evils, and we should take it until warning() learns to
handle lines breaks better.

-Peff
Junio C Hamano Aug. 5, 2019, 6:49 p.m. UTC | #4
Jeff King <peff@peff.net> writes:

>>  		OPT_STRING('s', "source", &opts.from_treeish, "<tree-ish>",
>> -			   N_("where the checkout from")),
>> +			   N_("where the checkout is from")),
>
> I think your original "where to checkout from" is better.

Would we even want to do s/where/which tree-ish/?

> translators, but note that the output will be different. The original
> would be something like:
>
>   warning: Fetch normally indicates...
>   warning: To re-enable...
>
> where now we'd get:
>
>   warning: Fetch normally indicates...
>   check has been disabled...
>   or run 'git config...
>
> which might be a bit harder to read because the wrapped lines lose the
> prefix. For advise() we nicely pick out the newlines and prefix each
> line individually, but warning(), error(), etc, don't do that. Maybe
> they should.

Yeah, I'd be surprised that nobody thought of doing that, so perhaps
somebody tried and failed with a possible fallout.  I do not offhand
see any downside of teaching them to do the prefixing.

For existing multi-line warnings that uses a single call to
warning(), I think the preparer of the message manually indents the
second and subsequent line by a run of SPs to match the screen width
of "warning:" prefix (and expect translators to do the same with
their language), and we need to get rid of that kind of "hack" when
we insert a middle layer between *_builtin() and vreportf() to do
the line chomping to produce output similar to advise() code.

> That's too big for this late in the -rc cycle, I think.

Agreed.
Thanks.
Jeff King Aug. 5, 2019, 9:15 p.m. UTC | #5
On Mon, Aug 05, 2019 at 11:49:46AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> >>  		OPT_STRING('s', "source", &opts.from_treeish, "<tree-ish>",
> >> -			   N_("where the checkout from")),
> >> +			   N_("where the checkout is from")),
> >
> > I think your original "where to checkout from" is better.
> 
> Would we even want to do s/where/which tree-ish/?

Yeah, I think that is even better.

> > prefix. For advise() we nicely pick out the newlines and prefix each
> > line individually, but warning(), error(), etc, don't do that. Maybe
> > they should.
> 
> Yeah, I'd be surprised that nobody thought of doing that, so perhaps
> somebody tried and failed with a possible fallout.  I do not offhand
> see any downside of teaching them to do the prefixing.

I know we've discussed it before, but a quick search of the archive only
came up with instances of me suggesting we should do it. ;)

Besides the obvious fallout you mentioned where callers might need to
drop their own custom indenting, it's possible people might be less
happy for output like:

  warning: a thing happened to these paths:
          foo
	  bar

where people might prefer not having a prefix on the subsequent lines,
because it makes it easier to cut-and-paste.

Anyway, that is all out of scope for this patch.

-Peff
diff mbox series

Patch

diff --git a/builtin/checkout.c b/builtin/checkout.c
index 91f8509f85..08e19ed1ed 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1769,7 +1769,7 @@  int cmd_restore(int argc, const char **argv, const char *prefix)
 	struct option *options;
 	struct option restore_options[] = {
 		OPT_STRING('s', "source", &opts.from_treeish, "<tree-ish>",
-			   N_("where the checkout from")),
+			   N_("where the checkout is from")),
 		OPT_BOOL('S', "staged", &opts.checkout_index,
 			   N_("restore the index")),
 		OPT_BOOL('W', "worktree", &opts.checkout_worktree,
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 53ce99d2bb..0e8760e5d4 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -850,6 +850,15 @@  static int iterate_ref_map(void *cb_data, struct object_id *oid)
 	return 0;
 }
 
+static char warn_show_forced_updates[] =
+N_("Fetch normally indicates which branches had a forced update, but that\n"
+   "check has been disabled. To re-enable, use '--show-forced-updates' flag\n"
+   "or run 'git config fetch.showForcedUpdates true'.");
+static char warn_time_show_forced_updates[] =
+N_("It took %.2f seconds to check forced updates. You can use\n"
+   "'--no-show-forced-updates or run 'git config fetch.showForcedUpdates false'\n"
+   " to avoid this check.\n");
+
 static int store_updated_refs(const char *raw_url, const char *remote_name,
 			      int connectivity_checked, struct ref *ref_map)
 {
@@ -1005,12 +1014,10 @@  static int store_updated_refs(const char *raw_url, const char *remote_name,
 
 	if (advice_fetch_show_forced_updates) {
 		if (!fetch_show_forced_updates) {
-			warning(_("Fetch normally indicates which branches had a forced update, but that check has been disabled."));
-			warning(_("To re-enable, use '--show-forced-updates' flag or run 'git config fetch.showForcedUpdates true'."));
+                  warning(_(warn_show_forced_updates));
 		} else if (forced_updates_ms > FORCED_UPDATES_DELAY_WARNING_IN_MS) {
-			warning(_("It took %.2f seconds to check forced updates. You can use '--no-show-forced-updates'\n"),
+			warning(_(warn_time_show_forced_updates),
 				forced_updates_ms / 1000.0);
-			warning(_("or run 'git config fetch.showForcedUpdates false' to avoid this check.\n"));
 		}
 	}