Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Factorization of messages with similar meaning #1088

Closed
wants to merge 11 commits into from

Conversation

jnavila
Copy link

@jnavila jnavila commented Dec 1, 2021

This series is a meager attempt at rationalizing a small fraction of the internationalized messages. Sorry in advance for the dull task of reviewing these insipide patches.

Doing so has some positive effects:

  • non-translatable constant strings are kept out of the way for translators
  • messages with identical meaning are built identically
  • the total number of messages to translate is decreased.

Changes since V1:

  • took into account the comments, except for ref-filter.c where the proposed refactoring is not obvious.
  • added even more strings to the "cannot be used together" crowd.

Changes since V2:

  • fixed change of behaviour in tag.c
  • reverted sam changes as per Johannes Sixt comments

Changes since V3:

  • apply Oxford comma where needed
  • switch all options to " '%s' " style where i18n is applied.

Changes since V4:

  • Apply changes by René on tag.c
  • cosmetic changes

cc: Jeff King peff@peff.net
cc: Johannes Sixt j6t@kdbg.org
cc: Ævar Arnfjörð Bjarmason avarab@gmail.com
cc: René Scharfe l.s.r@web.de

@rimrul
Copy link

rimrul commented Dec 2, 2021

The patch series looks mostly good. I've left two comments on 637cc99 where you flipped the meaning in two instances.

I haven't looked at why tests fail, though.

archive.c Outdated
@@ -577,11 +577,11 @@ static int parse_archive_args(int argc, const char **argv,
if (remote)
die(_("Unexpected option --remote"));
if (exec)
die(_("Option --exec can only be used together with --remote"));
die(_("%s and %s are mutually exclusive"), "--exec", "--remote");
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be "%s requires %s"

@@ -1849,7 +1849,7 @@ int cmd_index_pack(int argc, const char **argv, const char *prefix)
if (from_stdin && !startup_info->have_repository)
die(_("--stdin requires a git repository"));
if (from_stdin && hash_algo)
die(_("--object-format cannot be used with --stdin"));
die(_("%s requires %s"), "--object-format", "--stdin");
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be "%s and %s are mutually exclusive".

@jnavila
Copy link
Author

jnavila commented Dec 2, 2021

Thank you for catching these mistakes. The build is failing because some error messages are checked.

@jnavila
Copy link
Author

jnavila commented Dec 3, 2021

/submit

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 3, 2021

Submitted as pull.1088.git.1638514909.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git pr-1088/jnavila/i18n-refactor-v1

To fetch this version to local tag pr-1088/jnavila/i18n-refactor-v1:

git fetch --no-tags https://github.com/gitgitgadget/git tag pr-1088/jnavila/i18n-refactor-v1

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 3, 2021

On the Git mailing list, Jeff King wrote (reply to this):

On Fri, Dec 03, 2021 at 07:01:39AM +0000, Jean-Noël Avila via GitGitGadget wrote:

> This series is a meager attempt at rationalizing a small fraction of the
> internationalized messages. Sorry in advance for the dull task of reviewing
> these insipide patches.
> 
> Doing so has some positive effects:
> 
>  * non-translatable constant strings are kept out of the way for translators
>  * messages with identical meaning are built identically
>  * the total number of messages to translate is decreased.
> 
> I'm inclined to even go a step further and turn these messages into #define
> or const strings. This would have the added benefits:
> 
>  * make sure that the messages to translate are identical
>  * create a library of message skeletons to be picked up when new messages
>    are needed
> 
> What do you think?

One slight negative of this approach is that it makes messages a bit
harder to grep for. It sometimes really nice to "git jump grep" for
specific messages you got to see where they're coming from.

I don't think that's a strong objection, though. If this is making the
translations overall more maintainable it might be worth the tradeoff.

We could also allow GIT_VERBOSE=1 or something to print the file/line of
error(), warning(), and die() messages, which solves the same problem. I
think Ævar might have had some patches in that direction.

-Peff

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 3, 2021

User Jeff King <peff@peff.net> has been added to the cc: list.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 3, 2021

On the Git mailing list, Johannes Sixt wrote (reply to this):

Am 03.12.21 um 22:55 schrieb Jeff King:
> On Fri, Dec 03, 2021 at 07:01:39AM +0000, Jean-Noël Avila via GitGitGadget wrote:
> 
>> This series is a meager attempt at rationalizing a small fraction of the
>> internationalized messages. Sorry in advance for the dull task of reviewing
>> these insipide patches.
>>
>> Doing so has some positive effects:
>>
>>  * non-translatable constant strings are kept out of the way for translators
>>  * messages with identical meaning are built identically
>>  * the total number of messages to translate is decreased.
>>
>> I'm inclined to even go a step further and turn these messages into #define
>> or const strings. This would have the added benefits:
>>
>>  * make sure that the messages to translate are identical
>>  * create a library of message skeletons to be picked up when new messages
>>    are needed
>>
>> What do you think?
> 
> One slight negative of this approach is that it makes messages a bit
> harder to grep for. It sometimes really nice to "git jump grep" for
> specific messages you got to see where they're coming from.

This can be mitigated by using, for example,

  git grep -e --stdin --and -e mutually

as long as the rewrite keeps the arguments on the same line with the
format strings, which it does.

Another aspect is that translators lose context. For example, "%s and %s
are mutally exclusive" may have to be translated differently depending
on what kind of text is substituted for %s. In this example it's
probably always command line options (I haven't checked), so not an
immediate problem. But something to keep in mind.

-- Hannes

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 3, 2021

User Johannes Sixt <j6t@kdbg.org> has been added to the cc: list.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 5, 2021

On the Git mailing list, Junio C Hamano wrote (reply to this):

Johannes Sixt <j6t@kdbg.org> writes:

> Another aspect is that translators lose context. For example, "%s and %s
> are mutally exclusive" may have to be translated differently depending
> on what kind of text is substituted for %s. In this example it's
> probably always command line options (I haven't checked), so not an
> immediate problem. But something to keep in mind.

Yup.  I do not think we are quite ready to have two identical msgid
strings to be translated into two different msgstr strings.  We've
briefly talked about pgettext() a few months ago, but nothing
concrete came out of it, as far as I can recall.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 5, 2021

On the Git mailing list, Jean-Noël AVILA wrote (reply to this):

On Sunday, 5 December 2021 08:31:38 CET Junio C Hamano wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
> 
> > Another aspect is that translators lose context. For example, "%s and %s
> > are mutally exclusive" may have to be translated differently depending
> > on what kind of text is substituted for %s. In this example it's
> > probably always command line options (I haven't checked), so not an
> > immediate problem. But something to keep in mind.
> 
> Yup.  I do not think we are quite ready to have two identical msgid
> strings to be translated into two different msgstr strings.  We've
> briefly talked about pgettext() a few months ago, but nothing
> concrete came out of it, as far as I can recall.
> 
> 

As a translator, I made sure that all the messages are with the same grammatical structure where the placeholders are only command line options. The same messages with placeholders are meant to convey exactly the same meaning at all their use point. We have all the control on the source code to tailor them so that one message model is only used with specific types of variables (options here). That's another reason why I was proposing to define and name them.

If needed, "%s and %s are mutually exclusive" could be turned into "options %s and %s are mutually exclusive" to make it clear that the placeholders can only hold option names.



@gitgitgadget
Copy link

gitgitgadget bot commented Dec 5, 2021

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Jean-Noël Avila via GitGitGadget"  <gitgitgadget@gmail.com> writes:

> This series is a meager attempt at rationalizing a small fraction of the
> internationalized messages. Sorry in advance for the dull task of reviewing
> these insipide patches.
>
> Doing so has some positive effects:
>
>  * non-translatable constant strings are kept out of the way for translators
>  * messages with identical meaning are built identically
>  * the total number of messages to translate is decreased.
>
> I'm inclined to even go a step further and turn these messages into #define
> or const strings.

After looking at [01/10] that repeats the same string in many
places, I would have to say that we do not want such C preprocessor
macros.  Having to hunt for an existing message that is close enough
to what you want to say, when you are writing a new message, feels a
bit too much.

I wonder if a tool that

 - looks for "newly added" messages (by scanning "git diff" output)

 - compares them with po/git.pot for existing msgid in a fuzzy way
   to locate the ones that may be candidate for a change like the
   changes in this series

can help developers, though.

Thanks.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 5, 2021

On the Git mailing list, Johannes Sixt wrote (reply to this):

Am 05.12.21 um 18:25 schrieb Jean-Noël AVILA:
> If needed, "%s and %s are mutually exclusive" could be turned into
> "options %s and %s are mutually exclusive" to make it clear that the
> placeholders can only hold option names.

IMO, being less terse helps not only translators, but also users.

Regarding this particular message, personally, I am not a fan of
"mutually exclusive" (sounds like it's been taken from a law text). How
about "options ... are incompatible" or "... cannot be used together"?

-- Hannes

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 5, 2021

This branch is now known as ja/i18n-similar-messages.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 5, 2021

This patch series was integrated into seen via git@e5a04d9.

@gitgitgadget gitgitgadget bot added the seen label Dec 5, 2021
@gitgitgadget
Copy link

gitgitgadget bot commented Dec 6, 2021

On the Git mailing list, Junio C Hamano wrote (reply to this):

Johannes Sixt <j6t@kdbg.org> writes:

> Am 05.12.21 um 18:25 schrieb Jean-Noël AVILA:
>> If needed, "%s and %s are mutually exclusive" could be turned into
>> "options %s and %s are mutually exclusive" to make it clear that the
>> placeholders can only hold option names.
>
> IMO, being less terse helps not only translators, but also users.
>
> Regarding this particular message, personally, I am not a fan of
> "mutually exclusive" (sounds like it's been taken from a law text). How
> about "options ... are incompatible" or "... cannot be used together"?

Sounds good.  Or perhaps "X cannot be used with Y", which may be
even shorter and is still clear what it wants to say.

    X and Y are incompatible.
    X and Y cannot be used together.
    X cannot be used with Y.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 6, 2021

This patch series was integrated into seen via git@336152c.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 7, 2021

This patch series was integrated into seen via git@a61e664.

@@ -1621,7 +1621,7 @@ static int checkout_main(int argc, const char **argv, const char *prefix,
cb_option, toupper(cb_option));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):


On Fri, Dec 03 2021, Jean-Noël Avila via GitGitGadget wrote:

> From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
>
> Use static strings for constant parts of the sentences.
>
> Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
> ---
>  builtin/checkout.c          | 2 +-
>  builtin/diff-tree.c         | 2 +-
>  builtin/fetch.c             | 2 +-
>  builtin/init-db.c           | 2 +-
>  builtin/log.c               | 4 ++--
>  builtin/submodule--helper.c | 4 ++--
>  builtin/worktree.c          | 2 +-
>  range-diff.c                | 2 +-
>  8 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index cbf73b8c9f6..4bd8a57f190 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -1621,7 +1621,7 @@ static int checkout_main(int argc, const char **argv, const char *prefix,
>  				cb_option, toupper(cb_option));
>  
>  	if (opts->overlay_mode == 1 && opts->patch_mode)
> -		die(_("-p and --overlay are mutually exclusive"));
> +		die(_("%s and %s are mutually exclusive"), "-p", "--overlay");

It's good to do all of these, but I think we should really quote the
'%s' while at it. It also helps translators, who without that won't know
(without jumping to the source) if %s and %s are "walking" and "chewing
gum" or something like a CLI option that's quoted :)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Jean-Noël AVILA wrote (reply to this):

On Tuesday, 7 December 2021 19:07:41 CET �var Arnfj�r� Bjarmason wrote:
> 
> On Fri, Dec 03 2021, Jean-No�l Avila via GitGitGadget wrote:
> 
> > From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
> >
> > Use static strings for constant parts of the sentences.
> >
> > Signed-off-by: Jean-No�l Avila <jn.avila@free.fr>
> > ---
> >  builtin/checkout.c          | 2 +-
> >  builtin/diff-tree.c         | 2 +-
> >  builtin/fetch.c             | 2 +-
> >  builtin/init-db.c           | 2 +-
> >  builtin/log.c               | 4 ++--
> >  builtin/submodule--helper.c | 4 ++--
> >  builtin/worktree.c          | 2 +-
> >  range-diff.c                | 2 +-
> >  8 files changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/builtin/checkout.c b/builtin/checkout.c
> > index cbf73b8c9f6..4bd8a57f190 100644
> > --- a/builtin/checkout.c
> > +++ b/builtin/checkout.c
> > @@ -1621,7 +1621,7 @@ static int checkout_main(int argc, const char **argv, const char *prefix,
> >  				cb_option, toupper(cb_option));
> >  
> >  	if (opts->overlay_mode == 1 && opts->patch_mode)
> > -		die(_("-p and --overlay are mutually exclusive"));
> > +		die(_("%s and %s are mutually exclusive"), "-p", "--overlay");
> 
> It's good to do all of these, but I think we should really quote the
> '%s' while at it. It also helps translators, who without that won't know
> (without jumping to the source) if %s and %s are "walking" and "chewing
> gum" or something like a CLI option that's quoted :)
> 

With other comments included,  the proposition for this factorization would be:

"the options '%s' and '%s' cannot be used together"



@gitgitgadget
Copy link

gitgitgadget bot commented Dec 7, 2021

User Ævar Arnfjörð Bjarmason <avarab@gmail.com> has been added to the cc: list.

@@ -185,7 +185,7 @@ static int write_archive_entry(const struct object_id *oid, const char *base,

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):


On Fri, Dec 03 2021, Jean-Noël Avila via GitGitGadget wrote:

> From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
>
> Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
> ---
>  archive.c       | 4 ++--
>  builtin/fetch.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/archive.c b/archive.c
> index 10376be7161..f1208beacff 100644
> --- a/archive.c
> +++ b/archive.c
> @@ -185,7 +185,7 @@ static int write_archive_entry(const struct object_id *oid, const char *base,
>  
>  	buffer = object_file_to_archive(args, path.buf, oid, mode, &type, &size);
>  	if (!buffer)
> -		return error(_("cannot read %s"), oid_to_hex(oid));
> +		return error(_("cannot read '%s'"), oid_to_hex(oid));

Re my just-sent comment, i.e. quote things like that, but between this
and the first patch there's a bunch that don't use quotes that could use
them...

@@ -522,7 +522,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
finalize_colopts(&colopts, -1);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):


On Fri, Dec 03 2021, Jean-Noël Avila via GitGitGadget wrote:

> From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
>
> Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
> ---
>  builtin/tag.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/tag.c b/builtin/tag.c
> index 41941d5129f..6415d6c81a2 100644
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -543,13 +543,13 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
>  		goto cleanup;
>  	}
>  	if (filter.lines != -1)
> -		die(_("-n option is only allowed in list mode"));
> +		die(_("%s option is only allowed in list mode"), "-n");
>  	if (filter.with_commit)
> -		die(_("--contains option is only allowed in list mode"));
> +		die(_("%s option is only allowed in list mode"), "--contains");
>  	if (filter.no_commit)
> -		die(_("--no-contains option is only allowed in list mode"));
> +		die(_("%s option is only allowed in list mode"), "--no-contains");
>  	if (filter.points_at.nr)
> -		die(_("--points-at option is only allowed in list mode"));
> +		die(_("%s option is only allowed in list mode"), "--points-at");
>  	if (filter.reachable_from || filter.unreachable_from)
>  		die(_("--merged and --no-merged options are only allowed in list mode"));
>  	if (cmdmode == 'd') {

Since for all of these we're asking translators to re-do some work
(albeit with translation memory) this could use a bit of grammar
improvement. E.g.:

    _("the '%s' option is only allowed in list mode'")

I.e. "blah option is only" without a "the" is a bit odd.

But also for this & various other boilerplate in this series, I think it
would be much better as say:

    const char *only_in_list = NULL;
    if (...)
        only_in_list = "-n";
    else if (...)
        only_in_list = "--contains";
    [...]
    if (only_in_list)
        die(__("the '%s' option [...]"), only_in_list);

I.e. we're buying ourselves the chance to easily get a rid of a lot of
this repetition, but aren't using it. I think a series like this should
probably resist some big refactorings, but things like that would be
pretty easy & make the code more readable.

@@ -341,7 +341,7 @@ static int objectsize_atom_parser(struct ref_format *format, struct used_atom *a
else
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this):


On Fri, Dec 03 2021, Jean-Noël Avila via GitGitGadget wrote:

> From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
>
> Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
> ---
>  ref-filter.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/ref-filter.c b/ref-filter.c
> index 08a3f839c97..554c2ba1b17 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -341,7 +341,7 @@ static int objectsize_atom_parser(struct ref_format *format, struct used_atom *a
>  		else
>  			oi.info.disk_sizep = &oi.disk_size;
>  	} else
> -		return strbuf_addf_ret(err, -1, _("unrecognized %%(objectsize) argument: %s"), arg);
> +		return strbuf_addf_ret(err, -1, _("unrecognized %%(%s) argument: %s"), "objectsize", arg);
>  	return 0;
>  }
>  
> @@ -374,7 +374,7 @@ static int subject_atom_parser(struct ref_format *format, struct used_atom *atom
>  	else if (!strcmp(arg, "sanitize"))
>  		atom->u.contents.option = C_SUB_SANITIZE;
>  	else
> -		return strbuf_addf_ret(err, -1, _("unrecognized %%(subject) argument: %s"), arg);
> +		return strbuf_addf_ret(err, -1, _("unrecognized %%(%s) argument: %s"), "subject", arg);
>  	return 0;
>  }
>  
> @@ -428,7 +428,7 @@ static int contents_atom_parser(struct ref_format *format, struct used_atom *ato
>  		if (strtoul_ui(arg, 10, &atom->u.contents.nlines))
>  			return strbuf_addf_ret(err, -1, _("positive value expected contents:lines=%s"), arg);
>  	} else
> -		return strbuf_addf_ret(err, -1, _("unrecognized %%(contents) argument: %s"), arg);
> +		return strbuf_addf_ret(err, -1, _("unrecognized %%(%s) argument: %s"), "contents", arg);
>  	return 0;
>  }
>  
> @@ -440,7 +440,7 @@ static int raw_atom_parser(struct ref_format *format, struct used_atom *atom,
>  	else if (!strcmp(arg, "size"))
>  		atom->u.raw_data.option = RAW_LENGTH;
>  	else
> -		return strbuf_addf_ret(err, -1, _("unrecognized %%(raw) argument: %s"), arg);
> +		return strbuf_addf_ret(err, -1, _("unrecognized %%(%s) argument: %s"), "raw", arg);
>  	return 0;
>  }
>  
> @@ -531,7 +531,7 @@ static int align_atom_parser(struct ref_format *format, struct used_atom *atom,
>  		else if ((position = parse_align_position(s)) >= 0)
>  			align->position = position;
>  		else {
> -			strbuf_addf(err, _("unrecognized %%(align) argument: %s"), s);
> +			strbuf_addf(err, _("unrecognized %%(%s) argument: %s"), "align", s);
>  			string_list_clear(&params, 0);
>  			return -1;
>  		}
> @@ -557,7 +557,7 @@ static int if_atom_parser(struct ref_format *format, struct used_atom *atom,
>  	} else if (skip_prefix(arg, "notequals=", &atom->u.if_then_else.str)) {
>  		atom->u.if_then_else.cmp_status = COMPARE_UNEQUAL;
>  	} else
> -		return strbuf_addf_ret(err, -1, _("unrecognized %%(if) argument: %s"), arg);
> +		return strbuf_addf_ret(err, -1, _("unrecognized %%(%s) argument: %s"), "if", arg);
>  	return 0;
>  }

Maybe too big a refactoring, but doesn't the parent function here know
the "name" and could just pass it along?

Or actually not pass it at all and just have all of these be say:

    return -2;

And we'd do the error one caller above this if we get a return code of
-2.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 7, 2021

This patch series was integrated into seen via git@190b117.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 8, 2021

This patch series was integrated into seen via git@f1e1620.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 8, 2021

There was a status update in the "New Topics" section about the branch ja/i18n-similar-messages on the Git mailing list:

Similar message templates have been consolidated so that
translators need to work on fewer number of messages.

Needs review.
source: <pull.1088.git.1638514909.gitgitgadget@gmail.com>

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 8, 2021

This patch series was integrated into seen via git@f8dc6ad.

@gitgitgadget
Copy link

gitgitgadget bot commented Dec 9, 2021

This patch series was integrated into seen via git@5e0f758.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 4, 2022

This patch series was integrated into seen via git@75209e8.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 4, 2022

There was a status update in the "Cooking" section about the branch ja/i18n-similar-messages on the Git mailing list:

Similar message templates have been consolidated so that
translators need to work on fewer number of messages.

cf. <48262743.WQR3eRXon5@cayenne>
source: <pull.1088.v4.git.1641143745.gitgitgadget@gmail.com>

Use placeholders for constant tokens. The strings are turned into
"cannot be used together"

Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
They are all replaced by "the option '%s' requires '%s'", which is a
new string but replaces 17 previous unique strings.

Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
Even if some of these messages are not subject to gettext i18n, this
helps bring a single style of message for a given error type.

Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
@gitgitgadget
Copy link

gitgitgadget bot commented Jan 5, 2022

This patch series was integrated into seen via git@945f0e3.

@jnavila
Copy link
Author

jnavila commented Jan 5, 2022

/submit

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 5, 2022

Submitted as pull.1088.v5.git.1641412944.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git pr-1088/jnavila/i18n-refactor-v5

To fetch this version to local tag pr-1088/jnavila/i18n-refactor-v5:

git fetch --no-tags https://github.com/gitgitgadget/git tag pr-1088/jnavila/i18n-refactor-v5

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 5, 2022

On the Git mailing list, Johannes Sixt wrote (reply to this):

Am 05.01.22 um 21:02 schrieb Jean-Noël Avila via GitGitGadget:
> This series is a meager attempt at rationalizing a small fraction of the
> internationalized messages. Sorry in advance for the dull task of reviewing
> these insipide patches.
> 
> Doing so has some positive effects:
> 
>  * non-translatable constant strings are kept out of the way for translators
>  * messages with identical meaning are built identically
>  * the total number of messages to translate is decreased.
> 
> Changes since V1:
> 
>  * took into account the comments, except for ref-filter.c where the
>    proposed refactoring is not obvious.
>  * added even more strings to the "cannot be used together" crowd.
> 
> Changes since V2:
> 
>  * fixed change of behaviour in tag.c
>  * reverted sam changes as per Johannes Sixt comments
> 
> Changes since V3:
> 
>  * apply Oxford comma where needed
>  * switch all options to " '%s' " style where i18n is applied.
> 
> Changes since V4:
> 
>  * Apply changes by René on tag.c
>  * cosmetic changes

This round looks good to me, with one caveat: I am not a translator, nor
do I use a translated version of Git. So, I haven't verified the claim
that the number translatable strings was reduced greatly, nor whether
there are any accidential duplicates due to typos. I infer the
correctness only by looking at the changes.

There's one small nit visible in the range-diff; not worth a reroll IMHO:

>   5:  a9d8a50d666 !  5:  ad58bc8d8a9 i18n: tag.c factorize i18n strings
>      @@ builtin/tag.c: int cmd_tag(int argc, const char **argv, const char *prefix)
>       -		die(_("--no-contains option is only allowed in list mode"));
>       -	if (filter.points_at.nr)
>       -		die(_("--points-at option is only allowed in list mode"));
>      +-	if (filter.reachable_from || filter.unreachable_from)
>      +-		die(_("--merged and --no-merged options are only allowed in list mode"));
>       +		only_in_list = "-n";
>       +	else if (filter.with_commit)
>       +		only_in_list = "--contains";
>      @@ builtin/tag.c: int cmd_tag(int argc, const char **argv, const char *prefix)
>       +		only_in_list = "--no-contains";
>       +	else if (filter.points_at.nr)
>       +		only_in_list = "--points-at";
>      ++	else if (filter.reachable_from)
>      ++		only_in_list = "--merged";
>      ++	else if  (filter.unreachable_from)

An extra blank after the 'if'.

>      ++		only_in_list = "--no-merged";
>       +	if (only_in_list)
>       +		die(_("the '%s' option is only allowed in list mode"), only_in_list);
>      - 	if (filter.reachable_from || filter.unreachable_from)
>      --		die(_("--merged and --no-merged options are only allowed in list mode"));
>      -+		die(_("'--merged' and '--no-merged' options are only allowed in list mode"));
>        	if (cmdmode == 'd') {
>        		ret = delete_tags(argv);
>        		goto cleanup;

-- Hannes

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 5, 2022

On the Git mailing list, Junio C Hamano wrote (reply to this):

Johannes Sixt <j6t@kdbg.org> writes:

>>  * Apply changes by René on tag.c
>>  * cosmetic changes
>
> This round looks good to me, with one caveat: I am not a translator, nor
> do I use a translated version of Git. So, I haven't verified the claim
> that the number translatable strings was reduced greatly, nor whether
> there are any accidential duplicates due to typos. I infer the
> correctness only by looking at the changes.

Thanks, both.  Will queue with a touch-up for that doubled SP.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 5, 2022

This patch series was integrated into seen via git@94e0d6b.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 5, 2022

This patch series was integrated into seen via git@1bcea0d.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 6, 2022

There was a status update in the "Cooking" section about the branch ja/i18n-similar-messages on the Git mailing list:

Similar message templates have been consolidated so that
translators need to work on fewer number of messages.

Will merge to 'next'.
source: <pull.1088.v5.git.1641412944.gitgitgadget@gmail.com>

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 7, 2022

This patch series was integrated into seen via git@f7ea9db.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 7, 2022

This patch series was integrated into next via git@6440d8f.

@gitgitgadget gitgitgadget bot added the next label Jan 7, 2022
@gitgitgadget
Copy link

gitgitgadget bot commented Jan 10, 2022

This patch series was integrated into seen via git@c17de5a.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 10, 2022

This patch series was integrated into next via git@c17de5a.

@gitgitgadget
Copy link

gitgitgadget bot commented Jan 10, 2022

This patch series was integrated into master via git@c17de5a.

@gitgitgadget gitgitgadget bot added the master label Jan 10, 2022
@gitgitgadget gitgitgadget bot closed this Jan 10, 2022
@gitgitgadget
Copy link

gitgitgadget bot commented Jan 10, 2022

Closed via c17de5a.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants