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

[Martin Ågren]

On 10 October 2017 at 04:35, Changwoo Ryu  wrote:
> 2017-10-10 10:26 GMT+09:00 Junio C Hamano :
>> Jean-Noël AVILA  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

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

[Changwoo Ryu]

2017-10-10 10:26 GMT+09:00 Junio C Hamano :
> Jean-Noël AVILA  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

[Junio C Hamano]

Jean-Noël AVILA  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

[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

[Stefan Beller]

On Sun, Oct 8, 2017 at 9:14 PM, Martin Ågren  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

[Martin Ågren]

On 9 October 2017 at 03:30, Junio C Hamano  wrote:
> On Mon, Oct 9, 2017 at 9:51 AM, brian m. carlson
>  wrote:
>> On Sun, Oct 08, 2017 at 10:32:35AM +0100, Philip Oakley wrote:
>>> From: "Martin Ågren" 
>>> > - 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

[Junio C Hamano]

On Mon, Oct 9, 2017 at 9:51 AM, brian m. carlson
 wrote:
> On Sun, Oct 08, 2017 at 10:32:35AM +0100, Philip Oakley wrote:
>> From: "Martin Ågren" 
>> > - 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

[brian m. carlson]

On Sun, Oct 08, 2017 at 10:32:35AM +0100, Philip Oakley wrote:
> From: "Martin Ågren" 
> > - 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


signature.asc
Description: PGP signature

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

[Martin Ågren]

On 8 October 2017 at 11:32, Philip Oakley  wrote:
> From: "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.
...
>>  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

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

[Philip Oakley]

From: "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 
---
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