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
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 )
From: Jeff King <hidden> Date: 2016-06-15 23:03:11
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
On Thu, Dec 4, 2014 at 10:55 AM, Jeff King [off-list ref] wrote:
On Thu, Dec 04, 2014 at 09:29:04AM +0100, Torsten Bögershausen wrote:
quoted
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.
From: Michael J Gruber <hidden> Date: 2016-06-15 23:03:11
Ævar Arnfjörð Bjarmason schrieb am 04.12.2014 um 16:49:
On Thu, Dec 4, 2014 at 10:55 AM, Jeff King [off-list ref] wrote:
quoted
On Thu, Dec 04, 2014 at 09:29:04AM +0100, Torsten Bögershausen wrote:
quoted
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.
quoted
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
On Thu, Dec 4, 2014 at 5:12 PM, Michael J Gruber
[off-list ref] wrote:
Ævar Arnfjörð Bjarmason schrieb am 04.12.2014 um 16:49:
quoted
On Thu, Dec 4, 2014 at 10:55 AM, Jeff King [off-list ref] wrote:
quoted
On Thu, Dec 04, 2014 at 09:29:04AM +0100, Torsten Bögershausen wrote:
quoted
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.
quoted
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.
Hi Ulrich,
2014-12-04 8:32 GMT+01:00 Ulrich Windl [off-list ref]:
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
From: Jeff King <hidden> Date: 2016-06-15 23:03:12
On Thu, Dec 04, 2014 at 06:21:40PM +0100, Ævar Arnfjörð Bjarmason wrote:
quoted
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
On Thu, Dec 04, 2014 at 06:21:40PM +0100, Ævar Arnfjörð Bjarmason wrote:
quoted
quoted
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" ?
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
Ralf Thielow [off-list ref] schrieb am 04.12.2014 um 20:02 in
Nachricht
[off-list ref]:
Hi Ulrich,
2014-12-04 8:32 GMT+01:00 Ulrich Windl [off-list ref]:
quoted
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