git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Ævar Arnfjörð" <avarab@gmail.com>,
	"Vasco Almeida" <vascomalmeida@sapo.pt>,
	"Git List" <git@vger.kernel.org>,
	"Jiang Xin" <worldhello.net@gmail.com>
Subject: Re: [PATCH 05/21] i18n: sequencer: mark entire sentences for translation
Date: Sun, 22 May 2016 21:00:37 -0400	[thread overview]
Message-ID: <CAPig+cSoq=+jsKPrqOG5khgK64VvyuJ1_EeumFBFYiaLnL27UA@mail.gmail.com> (raw)
In-Reply-To: <xmqqk2ilbo2o.fsf@gitster.mtv.corp.google.com>

On Sun, May 22, 2016 at 8:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> For what it's worth I agree with you and disagree with Eric here and
>> Junio in the "[PATCH 03/21] i18n: advice: internationalize message for
>> conflicts" thread.
>>
>> Of course there's a trade-off in source code verbosity when you have
>> to change every occurance of (pseudocode):
>>
>>     "our %s failed" # %s can be revert or merge
>>
>> to:
>>
>>     if (action == "merge")
>>         gettext("our merge failed")
>>     elsif (action == "revert")
>>         gettext("our revert failed")
>>
>> But forcing the translator to turn every such occurrence that flows
>> naturally in English into "the '%s' command failed" leads to a worse
>> translation.
>>
>> For example, if I ever get around to doing the Icelandic translation
>> which I've had on my backlog I might translate something like this:
>> ...
>> I.e. even though you might be running "git merge" or "git revert" the
>> UI is talking about those terms in the translated using native terms
>> for the action of merging or reverting, but referring to the literal
>> command names in English.
>> ...
>> It just doesn't flow as well, and leads to a more verbose translation.
>
> OK.  I couldn't judge your example in Icelandic, but I have enough
> trust in you to believe your conclusion ;-).

I have no problem viewing the issue from either side (the sentence
referencing a *literal* command or the *action* of the command), and
understood that it could go either way when I wrote the review. What
threw me was that 3/21 seemed to be using the literal command in the
strings rather than the action, despite the commit message. For
instance:

    error(_("commit is not possible because ..."));
    error(_("merge is not possible because ..."));
    error(_("pull is not possible because ..."));
    error(_("revert is not possible because ..."));

In each case, the first word looks like a git command; it's not
particularly grammatically correct. Had Vasco instead changed them to:

    committing is not possible...
    merging is not possible...
    pulling is not possible...
    reverting is not posible...

then the issue likely would never have come up.

  reply	other threads:[~2016-05-23  1:00 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-18 15:27 [PATCH 00/21] i18n and tests updates Vasco Almeida
2016-05-18 15:27 ` [PATCH 01/21] i18n: builtin/remote.c: fix mark for translation Vasco Almeida
2016-05-18 15:27 ` [PATCH 02/21] i18n: advice: mark string about detached head " Vasco Almeida
2016-05-18 15:27 ` [PATCH 03/21] i18n: advice: internationalize message for conflicts Vasco Almeida
2016-05-18 19:24   ` Eric Sunshine
2016-05-18 21:00     ` Vasco Almeida
2016-05-18 21:31       ` Junio C Hamano
2016-05-18 15:27 ` [PATCH 04/21] i18n: transport: mark strings for translation Vasco Almeida
2016-05-18 15:27 ` [PATCH 05/21] i18n: sequencer: mark entire sentences " Vasco Almeida
2016-05-18 19:28   ` Eric Sunshine
2016-05-18 21:02     ` Vasco Almeida
2016-05-21 13:15       ` Ævar Arnfjörð Bjarmason
2016-05-23  0:44         ` Junio C Hamano
2016-05-23  1:00           ` Eric Sunshine [this message]
2016-05-18 15:27 ` [PATCH 06/21] i18n: sequencer: mark string " Vasco Almeida
2016-05-18 15:27 ` [PATCH 07/21] i18n: merge-octopus: mark messages " Vasco Almeida
2016-05-18 15:27 ` [PATCH 08/21] merge-octupus: use die shell function from git-sh-setup.sh Vasco Almeida
2016-05-18 15:27 ` [PATCH 09/21] i18n: rebase: fix marked string to use eval_gettext variant Vasco Almeida
2016-05-18 15:27 ` [PATCH 10/21] i18n: rebase: mark placeholder for translation Vasco Almeida
2016-05-18 15:27 ` [PATCH 11/21] i18n: bisect: simplify error message for i18n Vasco Almeida
2016-05-18 15:27 ` [PATCH 12/21] t6030: update to use test_i18ncmp Vasco Almeida
2016-05-18 15:27 ` [PATCH 13/21] i18n: git-sh-setup.sh: mark strings for translation Vasco Almeida
2016-05-18 15:27 ` [PATCH 14/21] i18n: rebase-interactive: " Vasco Almeida
2016-05-19 17:49   ` Eric Sunshine
2016-05-21 12:57   ` Ævar Arnfjörð Bjarmason
2016-05-21 14:05     ` Vasco Almeida
2016-05-18 15:27 ` [PATCH 15/21] i18n: rebase-interactive: mark here-doc " Vasco Almeida
2016-05-18 15:27 ` [PATCH 16/21] i18n: rebase-interactive: mark comments of squash " Vasco Almeida
2016-05-18 15:27 ` [PATCH 17/21] tests: use test_i18n* functions to suppress false positives Vasco Almeida
2016-05-18 15:27 ` [PATCH 18/21] tests: unpack-trees: update to use test_i18n* functions Vasco Almeida
2016-05-18 15:27 ` [PATCH 19/21] t9003: become resilient to GETTEXT_POISON Vasco Almeida
2016-05-19 18:34   ` Eric Sunshine
2016-05-19 21:31     ` Vasco Almeida
2016-05-20  3:30       ` Eric Sunshine
2016-05-20 16:39         ` Junio C Hamano
2016-05-20 17:22           ` Eric Sunshine
2016-05-20 17:39           ` Vasco Almeida
2016-05-20 17:50             ` Junio C Hamano
2016-05-20 17:59               ` Junio C Hamano
2016-05-20 18:21                 ` Vasco Almeida
2016-05-18 15:27 ` [PATCH 20/21] t4153: fix negated test_i18ngrep call Vasco Almeida
2016-05-18 15:27 ` [PATCH 21/21] t5523: use test_i18ngrep for negation Vasco Almeida

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPig+cSoq=+jsKPrqOG5khgK64VvyuJ1_EeumFBFYiaLnL27UA@mail.gmail.com' \
    --to=sunshine@sunshineco.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=vascomalmeida@sapo.pt \
    --cc=worldhello.net@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).