git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jan Hudec <bulb@ucw.cz>
To: Thomas Rast <trast@student.ethz.ch>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Jakub Narebski" <jnareb@gmail.com>,
	"Git Mailing List" <git@vger.kernel.org>
Subject: Re: Has anyone looked at Gettext support for Git itself?
Date: Mon, 17 May 2010 19:59:40 +0200	[thread overview]
Message-ID: <20100517175939.GA3575@efreet.light.src> (raw)
In-Reply-To: <201005171712.22763.trast@student.ethz.ch>

On Mon, May 17, 2010 at 17:12:22 +0200, Thomas Rast wrote:
> Ævar Arnfjörð Bjarmason wrote:
> > On Mon, May 17, 2010 at 14:32, Thomas Rast <trast@student.ethz.ch> wrote:
> > > Ævar Arnfjörð Bjarmason wrote:
> > >>
> > >> just prefix the calls to git with LC_ALL=C.
> > >
> > > And how exactly do you expect us to go back in history and prefix all
> > > invocations of git in all scripts with LC_ALL=C?
> > 
> > I don't expect you to. I just don't think it's unreasonable that if
> > Git were to be internationalized that it behave like every other *nix
> > program. If you have a Chinese locale and rely on the output of some
> > program being in English your scripts will break if the OS
> > subsequently upgrades to a new version of the program that has been
> > translated to Chinese.
> 
> I've bumped against these hysterical raisins in the past too, so you
> have my sympathy.  But git's API is the set of its plumbing commands,
> I/O, arguments and all.

The plumbing commands' output, obviously, may not become locale dependent
since it is indeed part of the API. It may sometimes print localized error
messages though where one can't really do anything besides relying them to
the user anyway.

There are cases though, where somebody calls *porcelain* commands in their
scripts and there they occasionally may need this LC_ALL=C thing. I suppose
having a global option to turn off localization might be useful for such
users.

> We do not give a similar promise for porcelain commands, which
> includes most of the frequently used commands that also have a bunch
> of translatable output like status, clone, fetch, branch, etc.  You
> could start by translating the helpful comments in status, commit and
> rebase -i.
> 
> However, I'm just trying to point out that your suggested solution
> 
> > The right way to handle that is to call programs like that with
> > LC_ALL=C.
> 
> will never fly, and that git will, e.g., never be able to consistently
> call a commit a "Version" [de] because for-each-ref must forever fill
> the %(type) field with "commit".

I would personally consider it too obvious that "programs like that" means
porcelain to mention it.

Most error messages may be translated even in plumbing though, just like they
are translated in standard unix commands.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

  reply	other threads:[~2010-05-17 17:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-15 22:10 Has anyone looked at Gettext support for Git itself? Ævar Arnfjörð Bjarmason
2010-05-16  0:03 ` Jakub Narebski
2010-05-16  1:12   ` Ævar Arnfjörð Bjarmason
2010-05-16  5:36     ` Dmitry Potapov
2010-05-16 13:12       ` Ævar Arnfjörð Bjarmason
2010-05-16 16:08     ` Jan Hudec
2010-05-16 17:37       ` Ævar Arnfjörð Bjarmason
2010-05-17 14:32         ` Thomas Rast
2010-05-17 14:53           ` Ævar Arnfjörð Bjarmason
2010-05-17 15:12             ` Thomas Rast
2010-05-17 17:59               ` Jan Hudec [this message]
2010-05-17 18:56                 ` Will Palmer
2010-05-18  7:51                   ` Michael J Gruber
2010-05-18  9:35                     ` Thomas Singer
2010-05-18 13:33                       ` Will Palmer
2010-05-22 11:01                         ` Jan Hudec
2010-05-19 15:43             ` demerphq
2010-05-16 16:53 ` Thomas Singer
2010-05-17 15:04 ` Marc Weber
2010-05-18  7:12 ` Peter Krefting

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20100517175939.GA3575@efreet.light.src \
    --to=bulb@ucw.cz \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=trast@student.ethz.ch \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).