[L10N] Kickoff of translation for Git 2.15.0 round 1

[L10N] Kickoff of translation for Git 2.15.0 round 1

[Jiang Xin]

Hi,

Git v2.15.0-rc0 has been released, and it's time to start new round of git l10n.
This time there are 68 updated messages need to be translated since last
update.

You can get it from the usual place:

    https://github.com/git-l10n/git-po/

As how to update your XX.po and help to translate Git, please see
"Updating a XX.po file" and other sections in “po/README" file.

--
Jiang Xin

[PATCH] submodule: avoid sentence-lego in translated string

[Martin Ågren]

We currently build an error message like "entry is a %s, not a commit",
where the placeholder will be replaced with "blob", "tag" or "tree".
Apart from those three placeholder words not being translated, in some
languages it might be awkward or impossible to ensure a grammatically
correct end result.

Shorten the error message to "entry is not a commit". We will still
error out, we will still give a hint about what is wrong, but we will
not be as explicit as before.

Alternatively, we could have different switch-cases for the different
types and pick one of three different error messages. We might still
want a `default` and maybe more tests. So go for this simpler approach
instead.

Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
I browsed the diff of the .pot and found an addition that looked a bit
translation-unfriendly. Maybe something like this?

 submodule.c                    | 4 ++--
 t/t5531-deep-submodule-push.sh | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/submodule.c b/submodule.c
index 63e7094e1..3d91dbfd5 100644
--- a/submodule.c
+++ b/submodule.c
@@ -796,8 +796,8 @@ static int check_has_commit(const struct object_id *oid, void *data)
 		cb->result = 0;
 		return 0;
 	default:
-		die(_("submodule entry '%s' (%s) is a %s, not a commit"),
-		    cb->path, oid_to_hex(oid), typename(type));
+		die(_("submodule entry '%s' (%s) is not a commit"),
+		    cb->path, oid_to_hex(oid));
 	}
 }
 
diff --git a/t/t5531-deep-submodule-push.sh b/t/t5531-deep-submodule-push.sh
index 39cb2c1c3..e4c98bbc5 100755
--- a/t/t5531-deep-submodule-push.sh
+++ b/t/t5531-deep-submodule-push.sh
@@ -305,7 +305,7 @@ test_expect_success 'submodule entry pointing at a tag is error' '
 	git -C work commit -m "bad commit" &&
 	test_when_finished "git -C work reset --hard HEAD^" &&
 	test_must_fail git -C work push --recurse-submodules=on-demand ../pub.git master 2>err &&
-	test_i18ngrep "is a tag, not a commit" err
+	test_i18ngrep "is not a commit" err
 '
 
 test_expect_success 'push fails if recurse submodules option passed as yes' '
-- 
2.15.0.rc0.37.gd35688db1

Re: [PATCH] submodule: avoid sentence-lego in translated string

[Philip Oakley]

From: "Martin Ågren" <martin.agren@gmail.com>
> We currently build an error message like "entry is a %s, not a commit",
> where the placeholder will be replaced with "blob", "tag" or "tree".
> Apart from those three placeholder words not being translated, in some
> languages it might be awkward or impossible to ensure a grammatically
> correct end result.
>
> Shorten the error message to "entry is not a commit". We will still
> error out, we will still give a hint about what is wrong, but we will
> not be as explicit as before.
>
> Alternatively, we could have different switch-cases for the different
> types and pick one of three different error messages. We might still
> want a `default` and maybe more tests. So go for this simpler approach
> instead.
>
> Signed-off-by: Martin Ågren <martin.agren@gmail.com>
> ---
> I browsed the diff of the .pot and found an addition that looked a bit
> translation-unfriendly. Maybe something like this?
>
> submodule.c                    | 4 ++--
> t/t5531-deep-submodule-push.sh | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/submodule.c b/submodule.c
> index 63e7094e1..3d91dbfd5 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -796,8 +796,8 @@ static int check_has_commit(const struct object_id 
> *oid, void *data)
>  cb->result = 0;
>  return 0;
>  default:
> - die(_("submodule entry '%s' (%s) is a %s, not a commit"),
> -     cb->path, oid_to_hex(oid), typename(type));
> + die(_("submodule entry '%s' (%s) is not a commit"),
> +     cb->path, oid_to_hex(oid));
Bikeshed,
 maybe:
"submodule entry '%s' (%s) is not a commit. It is a %s"
This puts the two parts in separate sentences?

--
Philip


>  }
> }
>
> diff --git a/t/t5531-deep-submodule-push.sh 
> b/t/t5531-deep-submodule-push.sh
> index 39cb2c1c3..e4c98bbc5 100755
> --- a/t/t5531-deep-submodule-push.sh
> +++ b/t/t5531-deep-submodule-push.sh
> @@ -305,7 +305,7 @@ test_expect_success 'submodule entry pointing at a tag 
> is error' '
>  git -C work commit -m "bad commit" &&
>  test_when_finished "git -C work reset --hard HEAD^" &&
>  test_must_fail git -C work push --recurse-submodules=on-demand ../pub.git 
> master 2>err &&
> - test_i18ngrep "is a tag, not a commit" err
> + test_i18ngrep "is not a commit" err
> '
>
> test_expect_success 'push fails if recurse submodules option passed as 
> yes' '
> -- 
> 2.15.0.rc0.37.gd35688db1
> 

Re: [PATCH] submodule: avoid sentence-lego in translated string

[Martin Ågren]

On 8 October 2017 at 11:32, Philip Oakley <philipoakley@iee.org> wrote:
> From: "Martin Ågren" <martin.agren@gmail.com>
>
>> We currently build an error message like "entry is a %s, not a commit",
>> where the placeholder will be replaced with "blob", "tag" or "tree".
>> Apart from those three placeholder words not being translated, in some
>> languages it might be awkward or impossible to ensure a grammatically
>> correct end result.
...
>>  default:
>> - die(_("submodule entry '%s' (%s) is a %s, not a commit"),
>> -     cb->path, oid_to_hex(oid), typename(type));
>> + die(_("submodule entry '%s' (%s) is not a commit"),
>> +     cb->path, oid_to_hex(oid));
>
> Bikeshed,
> maybe:
> "submodule entry '%s' (%s) is not a commit. It is a %s"
> This puts the two parts in separate sentences?

I'm not doing the Swedish translation, but if I did, I would find this
just as hard to translate as the original. There are two problems here.
The first is "blob"/"tag"/"tree". "Blob" is already used in the Swedish
translation, but "tag" should be "tagg" and "tree" should be "träd"
(IMHO).

The second problem is that even if all three words were valid Swedish
words, then (IMHO) using "en %s" instead of "a %s" would be needed to
make sense with "en blob" and "en tag", but it wouldn't work with "en
tree" which should arguably be "ett tree". (But to be clear, seeing any
of "en tree" and "ett tree" makes me shiver.)

I should perhaps have been clearer that grammatical problems might arise
from the "a". (It's more or less by chance that it works in English in
the first place. Luckily there is no type "aardvark", "index" or
"other".) But I wouldn't be surprised if there's a language out there
where "a" is not a problem, but something else is.

It just occurred to me that one approach would be something like "... is
of type '%s', not 'commit'" where "commit" should not be translated and
%s would be one of "blob", "tag" and "tree". That would be sort of in
line with what `git cat-file` does, but not quite. In cat-file it seems
natural because it's about the command-line argument, here it's in an
error string and seems a bit awkward.

Martin

[PATCH] i18n: add a missing space in message

[Jean-Noel Avila]

The message spans over 2 lines but the C conconcatenation does not add
the needed space between the two lines.

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
---
 sequencer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

This is a single change discovered while doing the localization task.

Moreover, what's the status of the options in '--<option>' in the
messages?  Must they be single-quoted or not? This may sound a bit
picky, but there has been some shifts from one form to the other in
the latest batch of strings, leading to fuzzy matchings. Settling on a
given "standard" would probably reduce translators'work.

diff --git a/sequencer.c b/sequencer.c
index 7886e2269..e258bb646 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -2558,7 +2558,7 @@ static enum check_level get_missing_commit_check_level(void)
 		return CHECK_WARN;
 	if (!strcasecmp("error", value))
 		return CHECK_ERROR;
-	warning(_("unrecognized setting %s for option"
+	warning(_("unrecognized setting %s for option "
 		  "rebase.missingCommitsCheck. Ignoring."), value);
 	return CHECK_IGNORE;
 }
-- 
2.14.0

Re: [PATCH] submodule: avoid sentence-lego in translated string

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

On Sun, Oct 08, 2017 at 10:32:35AM +0100, Philip Oakley wrote:
> From: "Martin Ågren" <martin.agren@gmail.com>
> > - die(_("submodule entry '%s' (%s) is a %s, not a commit"),
> > -     cb->path, oid_to_hex(oid), typename(type));
> > + die(_("submodule entry '%s' (%s) is not a commit"),
> > +     cb->path, oid_to_hex(oid));
> Bikeshed,
> maybe:
> "submodule entry '%s' (%s) is not a commit. It is a %s"
> This puts the two parts in separate sentences?

Languages with multiple grammatical genders are going to have problems
with this.  In French, "a tree" is "un arbre" (masculine), but "a tag"
is "une étiquette" (feminine).  We don't currently have a Spanish
translation, but this would break there as well.

Splitting the article out with the type name is still problematic for
languages where articles vary by case, like German, since the
translation might be reused in another place requiring a different case.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 867 bytes --]

Re: [PATCH] submodule: avoid sentence-lego in translated string

[Junio C Hamano]

On Mon, Oct 9, 2017 at 9:51 AM, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> On Sun, Oct 08, 2017 at 10:32:35AM +0100, Philip Oakley wrote:
>> From: "Martin Ågren" <martin.agren@gmail.com>
>> > - die(_("submodule entry '%s' (%s) is a %s, not a commit"),
>> > -     cb->path, oid_to_hex(oid), typename(type));
>> > + die(_("submodule entry '%s' (%s) is not a commit"),
>> > +     cb->path, oid_to_hex(oid));
>> Bikeshed,
>> maybe:
>> "submodule entry '%s' (%s) is not a commit. It is a %s"
>> This puts the two parts in separate sentences?
>
> Languages with multiple grammatical genders are going to have problems
> with this.  In French, "a tree" is "un arbre" (masculine), but "a tag"
> is "une étiquette" (feminine).  We don't currently have a Spanish
> translation, but this would break there as well.
>
> Splitting the article out with the type name is still problematic for
> languages where articles vary by case, like German, since the
> translation might be reused in another place requiring a different case.

While all of the above is correct, would we really need to subject typename()
to translation? IOW, can't we just treat 'blob', 'tree', 'commit' and
'tag' as-is,
as terms of art (i.e. with a specific or precise meaning within a
given discipline
or field and might have a different meaning in common usage)?

Re: [PATCH] submodule: avoid sentence-lego in translated string

[Martin Ågren]

On 9 October 2017 at 03:30, Junio C Hamano <gitster@pobox.com> wrote:
> On Mon, Oct 9, 2017 at 9:51 AM, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
>> On Sun, Oct 08, 2017 at 10:32:35AM +0100, Philip Oakley wrote:
>>> From: "Martin Ågren" <martin.agren@gmail.com>
>>> > - die(_("submodule entry '%s' (%s) is a %s, not a commit"),
>>> > -     cb->path, oid_to_hex(oid), typename(type));
>>> > + die(_("submodule entry '%s' (%s) is not a commit"),
>>> > +     cb->path, oid_to_hex(oid));
>>> Bikeshed,
>>> maybe:
>>> "submodule entry '%s' (%s) is not a commit. It is a %s"
>>> This puts the two parts in separate sentences?
>>
>> Languages with multiple grammatical genders are going to have problems
>> with this.  In French, "a tree" is "un arbre" (masculine), but "a tag"
>> is "une étiquette" (feminine).  We don't currently have a Spanish
>> translation, but this would break there as well.
>>
>> Splitting the article out with the type name is still problematic for
>> languages where articles vary by case, like German, since the
>> translation might be reused in another place requiring a different case.
>
> While all of the above is correct, would we really need to subject typename()
> to translation? IOW, can't we just treat 'blob', 'tree', 'commit' and
> 'tag' as-is,
> as terms of art (i.e. with a specific or precise meaning within a
> given discipline
> or field and might have a different meaning in common usage)?

In another subthread, I sort of suggested "... is of type '%s', not 'commit'".
So "commit" and "%s" would appear as the file-format-level terms that they are.
I think it looks odd but I guess it might work in Swedish, FWIW.

In this particular case, we could have three specific messages plus one default
message (which at the time shouldn't ever occur). Or we have one specific
message for the "tag"-case, which seems to have been Stefan's original
motivation, and a generic message for the other cases.

Re: [PATCH] submodule: avoid sentence-lego in translated string

[Stefan Beller]

On Sun, Oct 8, 2017 at 9:14 PM, Martin Ågren <martin.agren@gmail.com> wrote:
> In this particular case, we could have three specific messages plus one default
> message (which at the time shouldn't ever occur). Or we have one specific
> message for the "tag"-case, which seems to have been Stefan's original
> motivation, and a generic message for the other cases.

I think the original patch is an improvement for the translations,
but I'd really want to deliver as much information to the user,
(it's an error message after all, so tell as much as possible that can
be helpful,)
which is why I would prefer to keep `typename(type)` in there.

I always assumed that translators are aware of these issues and sort of
work around this somehow, maybe like this:

  "submodule entry '%s' (%s) is not a commit. It is of type %s"

Thanks,
Stefan

Re: [PATCH] submodule: avoid sentence-lego in translated string

[Jean-Noël AVILA]

On Monday, 9 October 2017, 09:47:26 CEST Stefan Beller wrote:

> I always assumed that translators are aware of these issues and sort of
> work around this somehow, maybe like this:
> 
>   "submodule entry '%s' (%s) is not a commit. It is of type %s"

Translators can be aware of the issue if the coder commented the 
internationalization string with some possible candidates for the placeholders 
when it is not clear unless you check in the source code. Much effort was 
poured into translating the technical terms in other parts of Git; it seems 
awkward to just step back in this occurence.

Re: [PATCH] submodule: avoid sentence-lego in translated string

[Junio C Hamano]

Jean-Noël AVILA <jn.avila@free.fr> writes:

> On Monday, 9 October 2017, 09:47:26 CEST Stefan Beller wrote:
>
>> I always assumed that translators are aware of these issues and sort of
>> work around this somehow, maybe like this:
>> 
>>   "submodule entry '%s' (%s) is not a commit. It is of type %s"
>
> Translators can be aware of the issue if the coder commented the 
> internationalization string with some possible candidates for the placeholders 
> when it is not clear unless you check in the source code. Much effort was 
> poured into translating the technical terms in other parts of Git; it seems 
> awkward to just step back in this occurence.

I do not see this particular case as "stepping back", though.

Our users do not spell "git cat-file -t commit v2.0^{commit}" with
'commit' translated to their language, right?  Shouldn't an error
message output use the same phrase the input side requests users to
use?

Re: [PATCH] submodule: avoid sentence-lego in translated string

[Changwoo Ryu]

2017-10-10 10:26 GMT+09:00 Junio C Hamano <gitster@pobox.com>:
> Jean-Noël AVILA <jn.avila@free.fr> writes:
>
>> On Monday, 9 October 2017, 09:47:26 CEST Stefan Beller wrote:
>>
>>> I always assumed that translators are aware of these issues and sort of
>>> work around this somehow, maybe like this:
>>>
>>>   "submodule entry '%s' (%s) is not a commit. It is of type %s"
>>
>> Translators can be aware of the issue if the coder commented the
>> internationalization string with some possible candidates for the placeholders
>> when it is not clear unless you check in the source code. Much effort was
>> poured into translating the technical terms in other parts of Git; it seems
>> awkward to just step back in this occurence.
>
> I do not see this particular case as "stepping back", though.
>
> Our users do not spell "git cat-file -t commit v2.0^{commit}" with
> 'commit' translated to their language, right?  Shouldn't an error
> message output use the same phrase the input side requests users to
> use?

Users know the limit of command-line translation. They type "commit"
to commit but they see translated "commit" in output messages. It is
actually confusing. But the untranslated English literals in the
middle of translated sentences does not remove the confusion but
increase it in a different way.

Re: [PATCH] submodule: avoid sentence-lego in translated string

[Martin Ågren]

On 10 October 2017 at 04:35, Changwoo Ryu <cwryu@debian.org> wrote:
> 2017-10-10 10:26 GMT+09:00 Junio C Hamano <gitster@pobox.com>:
>> Jean-Noël AVILA <jn.avila@free.fr> writes:
>>
>>> On Monday, 9 October 2017, 09:47:26 CEST Stefan Beller wrote:
>>>
>>>> I always assumed that translators are aware of these issues and sort of
>>>> work around this somehow, maybe like this:
>>>>
>>>>   "submodule entry '%s' (%s) is not a commit. It is of type %s"
>>>
>>> Translators can be aware of the issue if the coder commented the
>>> internationalization string with some possible candidates for the placeholders
>>> when it is not clear unless you check in the source code. Much effort was
>>> poured into translating the technical terms in other parts of Git; it seems
>>> awkward to just step back in this occurence.
>>
>> I do not see this particular case as "stepping back", though.
>>
>> Our users do not spell "git cat-file -t commit v2.0^{commit}" with
>> 'commit' translated to their language, right?  Shouldn't an error
>> message output use the same phrase the input side requests users to
>> use?

I thought Jean-Noël meant at least partially the translator-experience,
not just the user-experience, but I might be wrong.

I prepared a patch to give a TRANSLATORS:-comment, but then I realized
that we have more instances like this with `typename()`. Actually, quite
often we avoid the issue (intentionally or unintentionally) by writing
"of type %s", but other times, we do the "is a %s". So I don't know,
maybe it all works anyway. The regular translators have now received 10
mails (11 counting this) so might be aware of this particular string by
now. :-/

> Users know the limit of command-line translation. They type "commit"
> to commit but they see translated "commit" in output messages. It is
> actually confusing. But the untranslated English literals in the
> middle of translated sentences does not remove the confusion but
> increase it in a different way.

What you describe seems plausible, but I have to admit that I don't use
i18n-ized software myself.

Martin