threads / discuss / 46933
Subject: [L10N] Kickoff of translation for Git 2.15.0 round 1
Jiang XinHi,
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
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
Philip OakleyRe: [PATCH] submodule: avoid sentence-lego in translated string
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
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
brian m. carlsonRe: [PATCH] submodule: avoid sentence-lego in translated string
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
Junio C HamanoRe: [PATCH] submodule: avoid sentence-lego in translated string
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
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.
Stefan BellerRe: [PATCH] submodule: avoid sentence-lego in translated string
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
Jean-Noël AVILARe: [PATCH] submodule: avoid sentence-lego in translated string
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.
Junio C HamanoRe: [PATCH] submodule: avoid sentence-lego in translated string
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
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
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
Jean-Noel Avila[PATCH] i18n: add a missing space in message
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