git-gui i18n status?

git-gui i18n status?

[Shawn O. Pearce]

Now that git-gui 0.8.2 is out and git 1.5.3 is just around the corner
I am starting to think about bringing the git-gui i18n work into the
main git-gui tree, so we can start working from a common codebase.

Looking at the repository on repo.or.cz it looks like it needs to
be merged/rebased onto 0.8.2.  There is a trivial merge conflict,
but there are some more subtle ones caused by the movement of
the library directory initialization down lower in git-gui.sh.
For example translations won't be initialized if we have an issue
with the output of git-version and want to prompt the user.

What is the current plan?  Should I be looking at the master branch
of git://repo.or.cz/git-gui/git-gui-i18n.git for pulling?  Or are
folks expecting that this series will be cleaned up before I pull it?

-- 
Shawn.

Re: git-gui i18n status?

[Johannes Schindelin]

Hi,

[Cc'ed all contributors.  I mean, the real contributors, not just those 
with cheap talk ;-)]

On Sat, 1 Sep 2007, Shawn O. Pearce wrote:

> Now that git-gui 0.8.2 is out and git 1.5.3 is just around the corner I 
> am starting to think about bringing the git-gui i18n work into the main 
> git-gui tree, so we can start working from a common codebase.

Yes.

> Looking at the repository on repo.or.cz it looks like it needs to be 
> merged/rebased onto 0.8.2.  There is a trivial merge conflict, but there 
> are some more subtle ones caused by the movement of the library 
> directory initialization down lower in git-gui.sh. For example 
> translations won't be initialized if we have an issue with the output of 
> git-version and want to prompt the user.

Hmm.  I am not enough involved in i18n stuff to form a proper opinion 
here...  Do you suggest to move the initialisation earlier?

> What is the current plan?  Should I be looking at the master branch of 
> git://repo.or.cz/git-gui/git-gui-i18n.git for pulling?  Or are folks 
> expecting that this series will be cleaned up before I pull it?

My plan is to put out a cleaned up patch series:

- Christian's patches, consolidated, to

	- Makefile rules for translation
	- Infrastructure in the source (basically adding [mc ...] 
	  everywhere, and initialising msgcat)
	- po/git-gui.pot
	- glossary

Then I'd like to prepare consolidated patches for the individual 
languages, attributed to the author where unique, and to Nanako for 
Japanese (mentioning help from Junio), and to Paolo (mentioning help from 
Michele).

Junio, Michele, is that attribution enough for you?

All these patches will go through the mailing list, so that people can 
comment and suggest improvements.

I'll also try to bug Christian into looking through the output of

	git grep \" -- \*.sh \*.tcl | grep -vwe mc -e bind | less

to make sure that we did not forget a string.  ATM the output consists of 
300+ lines, so it is a bit boring.  Maybe I can improve that command, 
too...

(I see

	"Invalid arguments to git-version",
	"Last arm of $type $name must be default",
	"git-version >= x", "git-gui: fatal error",
	"Cannot move to top of working directory:\n\n$err",
	"error: no icon for $w state={$state} $path",
	"error: no desc for state={$state} $path",
	"Unstaging [short_path $path] from commit",
	"Adding [short_path $path]",
	"fatal: cannot stat path $path: No such file or directory",
	"Possible environment issues exist.[...]",
	"Loading$cur_s annotations...",
	"Loading annotation...",
	"Author:\t",
	"Committer:\t",
	"Original File:\t",
	"Originally By:\n",
	"In File: ",
	"Copied Or Moved Here By:\n",
	"fatal: Cannot resolve $l_trck",
	"branch: Created from $new_expr",
	"merge $new_expr: Fast-forward",
	"Updating working directory to '[_name $this]'...",
	"Checked out '$name'.",
	"class $class already declared",
	"wrong # args: field name value?",
	"class $class is sealed (cannot add new fields)",
	"field $name already declared",
	"wrong # args: method name args body (ifdeleted body)?",
	"make_toplevel topvar winvar {options}",
	"unsupported option $name",
	"Commit $PARENT appears to be corrupt",
	"warning: Tcl does not support encoding '$enc'.",
	"This repository currently has approximately [...]",
	"Loading diff of [escape_path $path]...",
	"Unable to display [escape_path $path]",
	"* Binary file (not showing content).",
	"Unable to display [escape_path $path]",
	"error: Unhandled 3 way diff marker: {$op}",
	"error: Unhandled 2 way diff marker: {$op}",
	"Unstaging [short_path $current_diff_path] from commit",
	"Adding [short_path $current_diff_path]", and
	"The following branches are not completely merged into [...]",

but I could have missed some, and it is possible some do not need [mc 
...].)

Ciao,
Dscho

Re: git-gui i18n status?

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Then I'd like to prepare consolidated patches for the individual 
> languages, attributed to the author where unique, and to Nanako for 
> Japanese (mentioning help from Junio), and to Paolo (mentioning help from 
> Michele).
>
> Junio, Michele, is that attribution enough for you?

I am just one of those with cheap talk -- no objection from me.

Re: git-gui i18n status?

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sat, 1 Sep 2007, Shawn O. Pearce wrote:
> > Looking at the repository on repo.or.cz it looks like it needs to be 
> > merged/rebased onto 0.8.2.  There is a trivial merge conflict, but there 
> > are some more subtle ones caused by the movement of the library 
> > directory initialization down lower in git-gui.sh. For example 
> > translations won't be initialized if we have an issue with the output of 
> > git-version and want to prompt the user.
> 
> Hmm.  I am not enough involved in i18n stuff to form a proper opinion 
> here...  Do you suggest to move the initialisation earlier?

Yea, I think that's what we are going to have to do here.  If we don't
setup the directory for the .msg files early enough than we cannot do
translations through [mc].  Unfortunately that means we have to also
break up the library initialization.

I'll try to work up a patch that does this.
 
> > What is the current plan?  Should I be looking at the master branch of 
> > git://repo.or.cz/git-gui/git-gui-i18n.git for pulling?  Or are folks 
> > expecting that this series will be cleaned up before I pull it?
> 
> My plan is to put out a cleaned up patch series:
...
> All these patches will go through the mailing list, so that people can 
> comment and suggest improvements.

OK, that works well for me.  Nice clean series to apply.
 
> I'll also try to bug Christian into looking through the output of
> 
> 	git grep \" -- \*.sh \*.tcl | grep -vwe mc -e bind | less
> 
> to make sure that we did not forget a string.  ATM the output consists of 
> 300+ lines, so it is a bit boring.  Maybe I can improve that command, 
> too...

Some of these are internal errors that should never be presented to
an end-user, and some are for reflog entries.   Here's a quick run
through of these:

      D == internal error message (developer only)
      R == reflog message
      T == probably should be translated

 D  "Invalid arguments to git-version",
 D  "Last arm of $type $name must be default",
 D  "git-version >= x",
 T  "git-gui: fatal error",
 T  "Cannot move to top of working directory:\n\n$err",
 D  "error: no icon for $w state={$state} $path",
 D  "error: no desc for state={$state} $path",
 T  "Unstaging [short_path $path] from commit",
 T  "Adding [short_path $path]",
 T  "fatal: cannot stat path $path: No such file or directory",
 T  "Possible environment issues exist.[...]",
 T  "Loading$cur_s annotations...",
 T  "Loading annotation...",
 T  "Author:\t",
 T  "Committer:\t",
 T  "Original File:\t",
 T  "Originally By:\n",
 T  "In File: ",
 T  "Copied Or Moved Here By:\n",
 T  "fatal: Cannot resolve $l_trck",
 R  "branch: Created from $new_expr",
 R  "merge $new_expr: Fast-forward",
 T  "Updating working directory to '[_name $this]'...",
 T  "Checked out '$name'.",
 D  "class $class already declared",
 D  "wrong # args: field name value?",
 D  "class $class is sealed (cannot add new fields)",
 D  "field $name already declared",
 D  "wrong # args: method name args body (ifdeleted body)?",
 D  "make_toplevel topvar winvar {options}",
 D  "unsupported option $name",
 T  "Commit $PARENT appears to be corrupt",
 T  "warning: Tcl does not support encoding '$enc'.",
 T  "This repository currently has approximately [...]",
 T  "Loading diff of [escape_path $path]...",
 T  "Unable to display [escape_path $path]",
 T  "* Binary file (not showing content).",
 T  "Unable to display [escape_path $path]",
 D  "error: Unhandled 3 way diff marker: {$op}",
 D  "error: Unhandled 2 way diff marker: {$op}",
 T  "Unstaging [short_path $current_diff_path] from commit",
 T  "Adding [short_path $current_diff_path]", and
 T  "The following branches are not completely merged into [...]",

Messages that I marked as 'D' shouldn't ever be shown to an end-user
as they represent a Tcl error from incorrect usage of an internal
function.  Translating these is fine but since it should never
appear unless there is a serious bug in git-gui its probably not
worth the translation effort.

Messages marked as 'R' appear in the reflog for the corresponding
branch, etc.  These are not currently translated by core Git so I
am not sure if we should translate them in git-gui.

Messages marked as 'T' above are most definately shown to
the end-user and should be translated, or at least offered for
translation.  I realize some terms have been kept in their English
form even after translation as there isn't a good way to translate
them into every language.

-- 
Shawn.

Re: git-gui i18n status?

[Shawn O. Pearce]

"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hmm.  I am not enough involved in i18n stuff to form a proper opinion 
> > here...  Do you suggest to move the initialisation earlier?
> 
> Yea, I think that's what we are going to have to do here.  If we don't
> setup the directory for the .msg files early enough than we cannot do
> translations through [mc].  Unfortunately that means we have to also
> break up the library initialization.
> 
> I'll try to work up a patch that does this.

This two patch series is based on my current master (gitgui-0.8.2).
Its also now in my pu branch.


>From fc703c209d415fe20ad5551465b5b68b8ab8b046 Mon Sep 17 00:00:00 2001
From: Shawn O. Pearce <spearce@spearce.org>
Date: Sat, 1 Sep 2007 21:58:29 -0400
Subject: [PATCH] git-gui: Locate the library directory early during startup

To support a localized version of git-gui we need to locate the
library directory early so we can initialize Tcl's msgcat package
to load translated messages from.  This needs to occur before we
declare our git-version proc so that errors related to locating
git or assessing its version can be reported to the end-user in
their preferred language.  However we have to keep the library
loading until after git-version has been declared, otherwise we
will fail to start git-gui if we are using a fake tclIndex that
was generated by our Makefile.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 git-gui.sh |   25 +++++++++++++++----------
 1 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/git-gui.sh b/git-gui.sh
index fa30ccc..4ea6e91 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -44,6 +44,20 @@ if {[catch {package require Tcl 8.4} err]
 
 ######################################################################
 ##
+## locate our library
+
+set oguilib {@@GITGUI_LIBDIR@@}
+set oguirel {@@GITGUI_RELATIVE@@}
+if {$oguirel eq {1}} {
+	set oguilib [file dirname [file dirname [file normalize $argv0]]]
+	set oguilib [file join $oguilib share git-gui lib]
+} elseif {[string match @@* $oguirel]} {
+	set oguilib [file join [file dirname [file normalize $argv0]] lib]
+}
+unset oguirel
+
+######################################################################
+##
 ## enable verbose loading?
 
 if {![catch {set _verbose $env(GITGUI_VERBOSE)}]} {
@@ -595,15 +609,6 @@ You are using [git-version]:
 ##
 ## configure our library
 
-set oguilib {@@GITGUI_LIBDIR@@}
-set oguirel {@@GITGUI_RELATIVE@@}
-if {$oguirel eq {1}} {
-	set oguilib [file dirname [file dirname [file normalize $argv0]]]
-	set oguilib [file join $oguilib share git-gui lib]
-} elseif {[string match @@* $oguirel]} {
-	set oguilib [file join [file dirname [file normalize $argv0]] lib]
-}
-
 set idx [file join $oguilib tclIndex]
 if {[catch {set fd [open $idx r]} err]} {
 	catch {wm withdraw .}
@@ -637,7 +642,7 @@ if {$idx ne {}} {
 } else {
 	set auto_path [concat [list $oguilib] $auto_path]
 }
-unset -nocomplain oguirel idx fd
+unset -nocomplain idx fd
 
 ######################################################################
 ##
-- 
1.5.3.rc7.30.g947ad2


>From d4b0ccd931cc29f35e8f8493445af27ea72ed03e Mon Sep 17 00:00:00 2001
From: Shawn O. Pearce <spearce@spearce.org>
Date: Sat, 1 Sep 2007 22:22:42 -0400
Subject: [PATCH] git-gui: Initialize Tcl's msgcat library for internationalization

Tcl's msgcat library and corresponding mc procedure can locate a
translated string for any user message, provided that it is first
given a directory where the *.msg files are located containing the
translations.

During installation we will place the translations in lib/msgs/,
so we need to inform msgcat of this location once we determine it
during startup.  Our source code tree however will store all of
the translations within the po/ directory, so we need to special
case this variant.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 git-gui.sh |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/git-gui.sh b/git-gui.sh
index 4ea6e91..486d36e 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -51,8 +51,12 @@ set oguirel {@@GITGUI_RELATIVE@@}
 if {$oguirel eq {1}} {
 	set oguilib [file dirname [file dirname [file normalize $argv0]]]
 	set oguilib [file join $oguilib share git-gui lib]
+	set oguimsg [file join $oguilib msgs]
 } elseif {[string match @@* $oguirel]} {
 	set oguilib [file join [file dirname [file normalize $argv0]] lib]
+	set oguimsg [file join [file dirname [file normalize $argv0]] po]
+} else {
+	set oguimsg [file join $oguilib msgs]
 }
 unset oguirel
 
@@ -76,6 +80,16 @@ if {![catch {set _verbose $env(GITGUI_VERBOSE)}]} {
 
 ######################################################################
 ##
+## Internationalization (i18n) through msgcat and gettext. See
+## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html
+
+package require msgcat
+namespace import ::msgcat::mc
+::msgcat::mcload $oguimsg
+unset oguimsg
+
+######################################################################
+##
 ## read only globals
 
 set _appname [lindex [file split $argv0] end]
-- 
1.5.3.rc7.30.g947ad2

-- 
Shawn.

Re: git-gui i18n status?

[Johannes Schindelin]

Hi,

On Sat, 1 Sep 2007, Shawn O. Pearce wrote:

> "Shawn O. Pearce" <spearce@spearce.org> wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > Hmm.  I am not enough involved in i18n stuff to form a proper opinion 
> > > here...  Do you suggest to move the initialisation earlier?
> > 
> > Yea, I think that's what we are going to have to do here.  If we don't
> > setup the directory for the .msg files early enough than we cannot do
> > translations through [mc].  Unfortunately that means we have to also
> > break up the library initialization.
> > 
> > I'll try to work up a patch that does this.
> 
> This two patch series is based on my current master (gitgui-0.8.2).
> Its also now in my pu branch.

Sound both good to me.  Christian?

Ciao,
Dscho

Re: git-gui i18n status?

[Johannes Schindelin]

Hi,

On Sat, 1 Sep 2007, Shawn O. Pearce wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > I'll also try to bug Christian into looking through the output of
> > 
> > 	git grep \" -- \*.sh \*.tcl | grep -vwe mc -e bind | less
> > 
> > to make sure that we did not forget a string.  ATM the output consists 
> > of 300+ lines, so it is a bit boring.  Maybe I can improve that 
> > command, too...

I'll have a look at them; no need to have them in the initial i18n commit, 
right?  Especially since the translations cannot contain them yet.

Ciao,
Dscho

P.S.: I seem to remember that Christian is away, so maybe we should just 
move forward.  So I'll first prepare the patch series (minus the changes 
you have in pu).

Re: git-gui i18n status?

[Michele Ballabio]

On Sunday 02 September 2007, Johannes Schindelin wrote:
> Then I'd like to prepare consolidated patches for the individual 
> languages, attributed to the author where unique, and to Nanako for 
> Japanese (mentioning help from Junio), and to Paolo (mentioning help from 
> Michele).
> 
> Junio, Michele, is that attribution enough for you?

That's fine with me.

Re: git-gui i18n status?

[Michele Ballabio]

On Sunday 02 September 2007, Johannes Schindelin wrote:
 > Then I'd like to prepare consolidated patches for the individual
 > languages, attributed to the author where unique, and to Nanako for
 > Japanese (mentioning help from Junio), and to Paolo (mentioning help 
from
 > Michele).
 >
 > Junio, Michele, is that attribution enough for you?

That's fine with me.

(Since I'm having problems with my MUA this message may break the thread
and I'm not CC'ing everyone but Johannes and the ML. Sorry.)

Re: git-gui i18n status?

[Christian Stimming]

Hi Shawn et al.,

Am Sonntag, 2. September 2007 14:20 schrieb Johannes Schindelin:
> > > > Hmm.  I am not enough involved in i18n stuff to form a proper opinion
> > > > here...  Do you suggest to move the initialisation earlier?
> > >
> > > Yea, I think that's what we are going to have to do here.  If we don't
> > > setup the directory for the .msg files early enough than we cannot do
> > > translations through [mc].  Unfortunately that means we have to also
> > > break up the library initialization.
> > >
> > > I'll try to work up a patch that does this.
> >
> > This two patch series is based on my current master (gitgui-0.8.2).
> > Its also now in my pu branch.
>
> Sound both good to me.  Christian?

Thanks for including the i18n framework and existing translations into the 
master of git-gui. I loosely watched the progress here, but due to other 
commitments I cannot spend as much time on git-gui i18n as I initially 
thought. I'd happily update and polish the German translation, though (will 
send other email for that), but I probably can't follow any of the ongoing 
i18n cleanup work.

One question came up when seeing the i18n code really in git-gui.git: How are 
translators supposed to submit new or updated translations? Is 
git-gui-i18n.git of any use anymore? This doesn't seem so. Should updated 
translations just be submitted by email to git@vger? In any case, the 
instructions in po/README should probably be updated to explain the 
recommended way of submitting translation updates. 

Oh, and po/git-gui.pot should probably be updated to reflect the latest string 
additions and changes. 

Thanks a lot.

Christian

Re: git-gui i18n status?

[Shawn O. Pearce]

Christian Stimming <stimming@tuhh.de> wrote:
> One question came up when seeing the i18n code really in git-gui.git: How are 
> translators supposed to submit new or updated translations? Is 
> git-gui-i18n.git of any use anymore? This doesn't seem so. Should updated 
> translations just be submitted by email to git@vger? In any case, the 
> instructions in po/README should probably be updated to explain the 
> recommended way of submitting translation updates. 

I was sort of hoping Dscho would be able to answer that.  ;-)

I can play patch-monkey and apply things people send to the mailing
list.  I'm also willing to pull from a tree if the commit history
is clean and mergable.  Since each language more or less stands
on its own in its own .po file translators may find it easier to
email patches.  I dunno, I'm not a translator.
 
> Oh, and po/git-gui.pot should probably be updated to reflect the latest string 
> additions and changes. 

Yes.  Dscho was looking at creating a custom diff filter for git
that would better handle showing diffs here.  I was sort of waiting
for progress from that (if any) before doing the pot update.  I also
have a lot of UI work that I wanted to do in the 0.9.x series and
those are likely to create/change the sets of messages we need
to translate.

-- 
Shawn.

Re: git-gui i18n status?

[Johannes Schindelin]

Hi,

On Sun, 16 Sep 2007, Shawn O. Pearce wrote:

> Christian Stimming <stimming@tuhh.de> wrote:
>
> > One question came up when seeing the i18n code really in git-gui.git: 
> > How are translators supposed to submit new or updated translations? Is 
> > git-gui-i18n.git of any use anymore? This doesn't seem so. Should 
> > updated translations just be submitted by email to git@vger? In any 
> > case, the instructions in po/README should probably be updated to 
> > explain the recommended way of submitting translation updates.
> 
> I was sort of hoping Dscho would be able to answer that.  ;-)

Heh.  Yeah, sorry...  I got sidetracked with other stuff.

Will try to find some time for i18n,
Dscho