Enhancement Request: "locale" git option

Enhancement Request: "locale" git option

[Ulrich Windl]

Hi!

I'm native German, but German git messages confuse me (yopu'll have to correlate them with the man pages). At the moment git uses the locale settings from the environment, so you can only change git's locale settings by changing the environment (like "LANG= git ...").
OTOH Git has a flexible hierachical option setting mechanism. Why not allow a Git language (locale) setting system-wde, user-wide, or repository-specific.

Regards,
Ulrich

Re: Enhancement Request: "locale" git option

[Torsten Bögershausen]

On 12/04/2014 08:32 AM, Ulrich Windl wrote:
> Hi!
>
> I'm native German, but German git messages confuse me (yopu'll have to correlate them with the man pages). At the moment git uses the locale settings from the environment, so you can only change git's locale settings by changing the environment (like "LANG= git ...").
> OTOH Git has a flexible hierachical option setting mechanism. Why not allow a Git language (locale) setting system-wde, user-wide, or repository-specific.
>
> Regards,
> Ulrich
How about
alias git='LANGUAGE=de_DE.UTF-8 git'
in your ~/.profile ?
(Of course you need to change de to the language you want )

Re: Enhancement Request: "locale" git option

[Jeff King]

On Thu, Dec 04, 2014 at 09:29:04AM +0100, Torsten Bögershausen wrote:

> How about
> alias git='LANGUAGE=de_DE.UTF-8 git'
> in your ~/.profile ?
> (Of course you need to change de to the language you want )

Besides being awkward in scripts (which will not respect the alias and
use a different language!), that variable will also be inherited by
programs git spawns. So the editor, for example, may end up in the wrong
language.

I think respecting core.locale would make sense (probably the change
would go into git_setup_gettext(), but you may have to fight with the
setup code over looking at config so early in the process).

However, I think the original question is not one of localizing git, but
rather of having it _not_ localized (avoiding the German translations).
There is a hack you can do that for that, which is to set
GIT_TEXTDOMAINDIR to something nonsensical (like "/"), which will mean
git cannot find the .po files, and just uses the builtin messages.

-Peff

Re: Enhancement Request: "locale" git option

[Ævar Arnfjörð Bjarmason]

On Thu, Dec 4, 2014 at 10:55 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Dec 04, 2014 at 09:29:04AM +0100, Torsten Bögershausen wrote:
>
>> How about
>> alias git='LANGUAGE=de_DE.UTF-8 git'
>> in your ~/.profile ?
>> (Of course you need to change de to the language you want )
>
> Besides being awkward in scripts (which will not respect the alias and
> use a different language!), that variable will also be inherited by
> programs git spawns. So the editor, for example, may end up in the wrong
> language.
>
> I think respecting core.locale would make sense (probably the change
> would go into git_setup_gettext(), but you may have to fight with the
> setup code over looking at config so early in the process).

I think we should just stick to the standard *nix way of doing this:
Tell people to set their locale in their environment.

If someone's having this issue it's also happening for all the
binutils, and any other command-line and GUI program they use, unless
they override using the standard way of doing so, by setting the
relevant LC_* environment variables.

If you want Git in English then create an alias to override its locale
to be C, if you want the editor it spawns to be in some other language
alias that to something that explicitly sets LC_* for that editor.

Maybe I'm being overzealous about this (especially with the "I
implemented this" blinders on), but let's not have Git set the
precedent for other *nix programs that they all should come up with
some custom way to override locales, that's something to be done at
the OS locale library level, which we use.

> However, I think the original question is not one of localizing git, but
> rather of having it _not_ localized (avoiding the German translations).
> There is a hack you can do that for that, which is to set
> GIT_TEXTDOMAINDIR to something nonsensical (like "/"), which will mean
> git cannot find the .po files, and just uses the builtin messages.

You can, but the fact that that works is an internal implementation
detail we shouldn't document or support.

Re: Enhancement Request: "locale" git option

[Michael J Gruber]

Ævar Arnfjörð Bjarmason schrieb am 04.12.2014 um 16:49:
> On Thu, Dec 4, 2014 at 10:55 AM, Jeff King <peff@peff.net> wrote:
>> On Thu, Dec 04, 2014 at 09:29:04AM +0100, Torsten Bögershausen wrote:
>>
>>> How about
>>> alias git='LANGUAGE=de_DE.UTF-8 git'
>>> in your ~/.profile ?
>>> (Of course you need to change de to the language you want )
>>
>> Besides being awkward in scripts (which will not respect the alias and
>> use a different language!), that variable will also be inherited by
>> programs git spawns. So the editor, for example, may end up in the wrong
>> language.
>>
>> I think respecting core.locale would make sense (probably the change
>> would go into git_setup_gettext(), but you may have to fight with the
>> setup code over looking at config so early in the process).
> 
> I think we should just stick to the standard *nix way of doing this:
> Tell people to set their locale in their environment.
> 
> If someone's having this issue it's also happening for all the
> binutils, and any other command-line and GUI program they use, unless
> they override using the standard way of doing so, by setting the
> relevant LC_* environment variables.
> 
> If you want Git in English then create an alias to override its locale
> to be C, if you want the editor it spawns to be in some other language
> alias that to something that explicitly sets LC_* for that editor.
> 
> Maybe I'm being overzealous about this (especially with the "I
> implemented this" blinders on), but let's not have Git set the
> precedent for other *nix programs that they all should come up with
> some custom way to override locales, that's something to be done at
> the OS locale library level, which we use.
> 
>> However, I think the original question is not one of localizing git, but
>> rather of having it _not_ localized (avoiding the German translations).
>> There is a hack you can do that for that, which is to set
>> GIT_TEXTDOMAINDIR to something nonsensical (like "/"), which will mean
>> git cannot find the .po files, and just uses the builtin messages.
> 
> You can, but the fact that that works is an internal implementation
> detail we shouldn't document or support.
> 

The main issue at hand is really that we have localised git but not its
man pages. Even if you understand English, the man pages don't help you
at all if you can't connect the technical terms used there to their
localised counterparts in git's messages. (NO_GETTEXT=y is my solution.)

That is one of the many reasons why I proposed to have a dictionary of
the main technical terms for each language before we even localise git
in that language. In an ideal word, we would provide a simple solution
for looking these terms up both ways. I don't think we're going to have
localised man pages any time soon, are we?

Michael

Re: Enhancement Request: "locale" git option

[Andreas Schwab]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> The main issue at hand is really that we have localised git but not its
> man pages. Even if you understand English, the man pages don't help you
> at all if you can't connect the technical terms used there to their
> localised counterparts in git's messages. (NO_GETTEXT=y is my solution.)

So the problem is just that the localisation is incomplete.  This is
unfortunate, but happens with a lot of software out there, and providing
a git-only solution doesn't help the case.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Enhancement Request: "locale" git option

[Ævar Arnfjörð Bjarmason]

On Thu, Dec 4, 2014 at 5:12 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Ævar Arnfjörð Bjarmason schrieb am 04.12.2014 um 16:49:
>> On Thu, Dec 4, 2014 at 10:55 AM, Jeff King <peff@peff.net> wrote:
>>> On Thu, Dec 04, 2014 at 09:29:04AM +0100, Torsten Bögershausen wrote:
>>>
>>>> How about
>>>> alias git='LANGUAGE=de_DE.UTF-8 git'
>>>> in your ~/.profile ?
>>>> (Of course you need to change de to the language you want )
>>>
>>> Besides being awkward in scripts (which will not respect the alias and
>>> use a different language!), that variable will also be inherited by
>>> programs git spawns. So the editor, for example, may end up in the wrong
>>> language.
>>>
>>> I think respecting core.locale would make sense (probably the change
>>> would go into git_setup_gettext(), but you may have to fight with the
>>> setup code over looking at config so early in the process).
>>
>> I think we should just stick to the standard *nix way of doing this:
>> Tell people to set their locale in their environment.
>>
>> If someone's having this issue it's also happening for all the
>> binutils, and any other command-line and GUI program they use, unless
>> they override using the standard way of doing so, by setting the
>> relevant LC_* environment variables.
>>
>> If you want Git in English then create an alias to override its locale
>> to be C, if you want the editor it spawns to be in some other language
>> alias that to something that explicitly sets LC_* for that editor.
>>
>> Maybe I'm being overzealous about this (especially with the "I
>> implemented this" blinders on), but let's not have Git set the
>> precedent for other *nix programs that they all should come up with
>> some custom way to override locales, that's something to be done at
>> the OS locale library level, which we use.
>>
>>> However, I think the original question is not one of localizing git, but
>>> rather of having it _not_ localized (avoiding the German translations).
>>> There is a hack you can do that for that, which is to set
>>> GIT_TEXTDOMAINDIR to something nonsensical (like "/"), which will mean
>>> git cannot find the .po files, and just uses the builtin messages.
>>
>> You can, but the fact that that works is an internal implementation
>> detail we shouldn't document or support.
>>
>
> The main issue at hand is really that we have localised git but not its
> man pages. Even if you understand English, the man pages don't help you
> at all if you can't connect the technical terms used there to their
> localised counterparts in git's messages. (NO_GETTEXT=y is my solution.)
>
> That is one of the many reasons why I proposed to have a dictionary of
> the main technical terms for each language before we even localise git
> in that language. In an ideal word, we would provide a simple solution
> for looking these terms up both ways. I don't think we're going to have
> localised man pages any time soon, are we?

I think that's a great idea, and one that's only blocked on someone
(hint hint) sending patches for it.

It would be neat-o to have something to make translating the docs
easier, i.e. PO files for sections of the man pages. There's tools to
help with that which we could use.

But there's no reason for us not to have translated glossaries in the meantime.

Re: Enhancement Request: "locale" git option

[Jeff King]

On Thu, Dec 04, 2014 at 06:21:40PM +0100, Ævar Arnfjörð Bjarmason wrote:

> > That is one of the many reasons why I proposed to have a dictionary of
> > the main technical terms for each language before we even localise git
> > in that language. In an ideal word, we would provide a simple solution
> > for looking these terms up both ways. I don't think we're going to have
> > localised man pages any time soon, are we?
> 
> I think that's a great idea, and one that's only blocked on someone
> (hint hint) sending patches for it.
> 
> It would be neat-o to have something to make translating the docs
> easier, i.e. PO files for sections of the man pages. There's tools to
> help with that which we could use.
> 
> But there's no reason for us not to have translated glossaries in the meantime.

By the way, there has been fairly significant volunteer effort put into
translating Pro Git (e.g., <http://git-scm.com/book/de/v1>). I have no
idea if the terms they use are similar to the terms we use in the
localized messages. It might make sense to:

  1. Coordinate with those translators to make sure that the glossary
     terms are consistent.

  2. Figure out how to harness those translators for manpage work. Why
     did Pro Git get so much volunteer translation done, and the
     manpages didn't? Did they advertise to the right people? Have an
     interface that made it easier for non-technical people to get
     involved?

-Peff

Re: Enhancement Request: "locale" git option

[Torsten Bögershausen]

On 12/04/2014 09:55 PM, Jeff King wrote:
> On Thu, Dec 04, 2014 at 06:21:40PM +0100, Ævar Arnfjörð Bjarmason wrote:
> 
>>> That is one of the many reasons why I proposed to have a dictionary of
>>> the main technical terms for each language before we even localise git
>>> in that language. In an ideal word, we would provide a simple solution
>>> for looking these terms up both ways. I don't think we're going to have
>>> localised man pages any time soon, are we?
>>
>> I think that's a great idea, and one that's only blocked on someone
>> (hint hint) sending patches for it.
>>
>> It would be neat-o to have something to make translating the docs
>> easier, i.e. PO files for sections of the man pages. There's tools to
>> help with that which we could use.
>>
>> But there's no reason for us not to have translated glossaries in the meantime.
> 
> By the way, there has been fairly significant volunteer effort put into
> translating Pro Git (e.g., <http://git-scm.com/book/de/v1>). I have no
> idea if the terms they use are similar to the terms we use in the
> localized messages. It might make sense to:
> 
>   1. Coordinate with those translators to make sure that the glossary
>      terms are consistent.
> 
>   2. Figure out how to harness those translators for manpage work. Why
>      did Pro Git get so much volunteer translation done, and the
>      manpages didn't? Did they advertise to the right people? Have an
>      interface that made it easier for non-technical people to get
>      involved?
> 
> -Peff

(Thanks for the pointer, excellent book)

I do not know who was first, and who came later, but 
<http://git-scm.com/book/de/v1/Git-Grundlagen-%C3%84nderungen-am-Repository-nachverfolgen>

uses "versioniert" as "tracked"


LANG=de_DE.UTF-8 git status
gives:
nichts zum Commit vorgemerkt, aber es gibt unbeobachtete Dateien (benutzen Sie "git add" zum Beobachten)


Does it make sense to replace "beobachten" with "versionieren" ?

Re: Enhancement Request: "locale" git option

[Ralf Thielow]

2014-12-05 16:45 GMT+01:00 Torsten Bögershausen <tboegi@web.de>:
>
> I do not know who was first, and who came later, but
> <http://git-scm.com/book/de/v1/Git-Grundlagen-%C3%84nderungen-am-Repository-nachverfolgen>
>
> uses "versioniert" as "tracked"
>
>
> LANG=de_DE.UTF-8 git status
> gives:
> nichts zum Commit vorgemerkt, aber es gibt unbeobachtete Dateien (benutzen Sie "git add" zum Beobachten)
>
>
> Does it make sense to replace "beobachten" with "versionieren" ?
>

I think it makes sense. "versionieren" describes the concept of tracking
better than "beobachten", IMO. I'll send a patch for that.

Thanks

Antw: Re: Enhancement Request: "locale" git option

[Ulrich Windl]

>>> Ralf Thielow <ralf.thielow@gmail.com> schrieb am 06.12.2014 um 20:28 in
Nachricht
<CAN0XMO+hn0cYrd=gVpUad_mQCvkNwdFzFLn0Vo7045-M_0Gsvw@mail.gmail.com>:
> 2014-12-05 16:45 GMT+01:00 Torsten Bögershausen <tboegi@web.de>:
>>
>> I do not know who was first, and who came later, but
>> 
>
<http://git-scm.com/book/de/v1/Git-Grundlagen-%C3%84nderungen-am-Repository-na

> chverfolgen>
>>
>> uses "versioniert" as "tracked"
>>
>>
>> LANG=de_DE.UTF-8 git status
>> gives:
>> nichts zum Commit vorgemerkt, aber es gibt unbeobachtete Dateien (benutzen

> Sie "git add" zum Beobachten)
>>
>>
>> Does it make sense to replace "beobachten" with "versionieren" ?
>>
> 
> I think it makes sense. "versionieren" describes the concept of tracking
> better than "beobachten", IMO. I'll send a patch for that.

Isolated from usage, "versionieren" and "tracking" have no common translation;
what about "verfolgen" (~follow) for "tracking"?

> 
> Thanks

Re: Antw: Re: Enhancement Request: "locale" git option

[David Kastrup]

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:

>>>> Ralf Thielow <ralf.thielow@gmail.com> schrieb am 06.12.2014 um 20:28 in
> Nachricht
> <CAN0XMO+hn0cYrd=gVpUad_mQCvkNwdFzFLn0Vo7045-M_0Gsvw@mail.gmail.com>:
>> 2014-12-05 16:45 GMT+01:00 Torsten Bögershausen <tboegi@web.de>:
>>>
>>> I do not know who was first, and who came later, but
>>> 
>>
> <http://git-scm.com/book/de/v1/Git-Grundlagen-%C3%84nderungen-am-Repository-na
>
>> chverfolgen>
>>>
>>> uses "versioniert" as "tracked"
>>>
>>>
>>> LANG=de_DE.UTF-8 git status
>>> gives:
>>> nichts zum Commit vorgemerkt, aber es gibt unbeobachtete Dateien (benutzen
>
>> Sie "git add" zum Beobachten)
>>>
>>>
>>> Does it make sense to replace "beobachten" with "versionieren" ?
>>>
>> 
>> I think it makes sense. "versionieren" describes the concept of tracking
>> better than "beobachten", IMO. I'll send a patch for that.
>
> Isolated from usage, "versionieren" and "tracking" have no common translation;
> what about "verfolgen" (~follow) for "tracking"?

What about "bekannt", "unbekannt" and "bekanntmachen"?  "unregistriert",
"registriert", "anmelden"?  Or "ungemeldet", "angemeldet", "anmelden"?

-- 
David Kastrup

Antw: Re: Enhancement Request: "locale" git option

[Ulrich Windl]

>>> Torsten Bögershausen <tboegi@web.de> schrieb am 04.12.2014 um 09:29 in
Nachricht <54801B50.4080500@web.de>:
> On 12/04/2014 08:32 AM, Ulrich Windl wrote:
>> Hi!
>>
>> I'm native German, but German git messages confuse me (yopu'll have to 
> correlate them with the man pages). At the moment git uses the locale 
> settings from the environment, so you can only change git's locale settings

> by changing the environment (like "LANG= git ...").
>> OTOH Git has a flexible hierachical option setting mechanism. Why not allow

> a Git language (locale) setting system-wde, user-wide, or
repository-specific.
>>
>> Regards,
>> Ulrich
> How about
> alias git='LANGUAGE=de_DE.UTF-8 git'
> in your ~/.profile ?
> (Of course you need to change de to the language you want )

That way no program ever needs configuration files ;-)

Re: Enhancement Request: "locale" git option

[Ralf Thielow]

Hi Ulrich,

2014-12-04 8:32 GMT+01:00 Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>:
> Hi!
>
> I'm native German, but German git messages confuse me (yopu'll have to correlate them with the man pages). At the moment git uses the

What in particular makes the German git messages confusing you? What
`git version` do you use?
Maybe we can find something to improve in the translation.

Thanks,
Ralf

Antw: Re: Enhancement Request: "locale" git option

[Ulrich Windl]

>>> Ralf Thielow <ralf.thielow@gmail.com> schrieb am 04.12.2014 um 20:02 in
Nachricht
<CAN0XMOL5ZZgEJ3zaXOAcxyX47iTM-DQv=+PNsdVrjD4aWwx2iw@mail.gmail.com>:
> Hi Ulrich,
> 
> 2014-12-04 8:32 GMT+01:00 Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>:
>> Hi!
>>
>> I'm native German, but German git messages confuse me (yopu'll have to 
> correlate them with the man pages). At the moment git uses the
> 
> What in particular makes the German git messages confusing you? What
> `git version` do you use?
> Maybe we can find something to improve in the translation.

The problem is (as others found out already) that all documentation I have use english Git messages, and lots of documentation is in English.

You could compare it to C++ (for example): If you read the language reference in English, you can only be confused by German compiler messages, and if you have a German book on C++, the phrases the book uses are quite likely not the ones the compiler uses...

Back to Git: Assuming (pure Science Fiction) that you participate in several projects using Git: One from a French maintainer expects that Git messages are in French, one Project uses English, another Project uses German... The a per-project locale setting would make sense (despite of the fact that I believe that every international project should use English for communication (just because it's a kind of "industry standard", not giving any personal preference).

Regards,
Ulrich

> 
> Thanks,
> Ralf