git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Has anyone looked at Gettext support for Git itself?

From
JHJan Hudec <bulb@ucw.cz>
Date
May 17, 2010, 17:59 UTC
Message-ID
<20100517175939.GA3575@efreet.light.src>
In-Reply-To
<201005171712.22763.trast@student.ethz.ch>
On Mon, May 17, 2010 at 17:12:22 +0200, Thomas Rast wrote:
Show 19 quoted lines
> Æ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.

Show 14 quoted lines
> 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>
Previous: Thomas RastNext: Will Palmer
Message 11 of 20 in “Has anyone looked at Gettext support for Git itself?”
  1. Ævar Arnfjörð BjarmasonMay 15, 2010
  2. Jakub NarebskiMay 16, 2010
  3. Ævar Arnfjörð BjarmasonMay 16, 2010
  4. Dmitry PotapovMay 16, 2010
  5. Ævar Arnfjörð BjarmasonMay 16, 2010
  6. Jan HudecMay 16, 2010
  7. Ævar Arnfjörð BjarmasonMay 16, 2010
  8. Thomas RastMay 17, 2010
  9. Ævar Arnfjörð BjarmasonMay 17, 2010
  10. Thomas RastMay 17, 2010
  11. Jan HudecMay 17, 2010
  12. Will PalmerMay 17, 2010
  13. Michael J GruberMay 18, 2010
  14. Thomas SingerMay 18, 2010
  15. Will PalmerMay 18, 2010
  16. Jan HudecMay 22, 2010
  17. demerphqMay 19, 2010
  18. Thomas SingerMay 16, 2010
  19. Marc WeberMay 17, 2010
  20. Peter KreftingMay 18, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.