git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jean-Noël AVILA" <jn.avila@free.fr>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>
Cc: Johannes Sixt <j6t@kdbg.org>, git@vger.kernel.org
Subject: Re: [PATCH 0/7] More i18n fixes
Date: Mon, 21 Mar 2022 21:13:01 +0100	[thread overview]
Message-ID: <2096494.irdbgypaU6@cayenne> (raw)
In-Reply-To: <xmqqlex3xh4d.fsf@gitster.g>

On Monday, 21 March 2022 20:03:46 CET Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
> >> Disclaimer: neither am I a translator nor a user of a translated Git.
> >
> > Just to add to this:
> >
> >  - Careful use of sentence lego is OK, but e.g. in my native language a
> >    command-line option would use a male noun article, whereas commands
> >    would be feminine.
> 
> Hmph, if we gather wisdom from folks with different native languages
> and varying rules, I am unsure that we still can say that "careful"
> use of sentence lego is OK.
> 

To me, this is not sentence lego because:
 * the placeholders are replacing constant strings that won't have declensions 
or grammatical agreements
 * the placeholders are linked to content where the variables have the same 
type, which makes them have the same genre for each language. This is the case 
for commands, options, env variables,...

Given these prerequisites, there's nothing that needs careful lego, because 
there is no risk at all. The only needed refinement, which I haven't addressed 
in this series,  is making it clear for the translator what the placeholder is 
referring to in order to get the wording correct.




  reply	other threads:[~2022-03-21 20:13 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-20 21:54 [PATCH 0/7] More i18n fixes Jean-Noël Avila via GitGitGadget
2022-03-20 21:54 ` [PATCH 1/7] i18n: factorize generic failure messages Jean-Noël Avila via GitGitGadget
2022-03-20 21:54 ` [PATCH 2/7] sequencer: factor GIT_AUTHOR_* from message strings Bagas Sanjaya via GitGitGadget
2022-03-21  5:22   ` Bagas Sanjaya
2022-03-20 21:54 ` [PATCH 3/7] i18n: factorize "bad argument" messages Jean-Noël Avila via GitGitGadget
2022-03-20 21:54 ` [PATCH 4/7] i18n: factorize "Server does not support foo" messages Jean-Noël Avila via GitGitGadget
2022-03-20 21:54 ` [PATCH 5/7] i18n: factorize "foo does not take arguments" messages Jean-Noël Avila via GitGitGadget
2022-03-20 21:54 ` [PATCH 6/7] i18n: factorize read-cache error messages Jean-Noël Avila via GitGitGadget
2022-03-20 21:54 ` [PATCH 7/7] i18n: factorize unrecognized options arguments messages Jean-Noël Avila via GitGitGadget
2022-03-21  6:48 ` [PATCH 0/7] More i18n fixes Johannes Sixt
2022-03-21 13:59   ` Ævar Arnfjörð Bjarmason
2022-03-21 19:03     ` Junio C Hamano
2022-03-21 20:13       ` Jean-Noël AVILA [this message]
2022-03-21 20:35     ` Jean-Noël AVILA
2022-04-02 16:10 ` [PATCH v2 0/6] " Jean-Noël Avila via GitGitGadget
2022-04-02 16:10   ` [PATCH v2 1/6] i18n: factorize generic failure messages Jean-Noël Avila via GitGitGadget
2022-04-03  5:56     ` Bagas Sanjaya
2022-04-03 14:34       ` Ævar Arnfjörð Bjarmason
2022-04-03 14:47     ` Ævar Arnfjörð Bjarmason
2022-04-02 16:10   ` [PATCH v2 2/6] sequencer: factor GIT_AUTHOR_* from message strings Bagas Sanjaya via GitGitGadget
2022-04-02 16:10   ` [PATCH v2 3/6] i18n: factorize server support messages in fetch-pack Jean-Noël Avila via GitGitGadget
2022-04-02 16:10   ` [PATCH v2 4/6] i18n: factorize "foo does not take arguments" messages Jean-Noël Avila via GitGitGadget
2022-04-03 14:39     ` Ævar Arnfjörð Bjarmason
2022-04-03 22:21       ` Junio C Hamano
2022-04-02 16:10   ` [PATCH v2 5/6] i18n: factorize read-cache error messages Jean-Noël Avila via GitGitGadget
2022-04-03 22:29     ` Junio C Hamano
2022-04-02 16:10   ` [PATCH v2 6/6] i18n: factorize "bad argument" messages Jean-Noël Avila via GitGitGadget
2022-04-03 14:41     ` Ævar Arnfjörð Bjarmason

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=2096494.irdbgypaU6@cayenne \
    --to=jn.avila@free.fr \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    /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).