Re: [PATCH] Internationalization of git-gui

Re: [PATCH] Internationalization of git-gui

[Brett Schwarz]

This is a good idea. However, I assume the _ proc is just sugar. It might be better to follow a more "standard" way for this, and just import the msgcat namespace, and then you can just use [mc]. For example:

package require msgcat
namespace import ::msgcat::*
  .
  .
  .
.mbar add cascade -label [mc Repository] -menu .mbar.repository

Also, if the message catalogs are in a common location, then it might be worth looking into having gitk utilize these msg catalogs as well.

Thanks,
    --brett


p.s. the frink tool (http://wiki.tcl.tk/2611) is supposed to be able to convert -text and -label switches to use msgcat...it might be worth looking into, instead of manually editing git-gui/gitk


----- Original Message ----
From: Christian Stimming <stimming@tuhh.de>
To: git@vger.kernel.org
Sent: Thursday, July 19, 2007 3:56:57 AM
Subject: [PATCH] Internationalization of git-gui

This is an initial patch of how internationalization (i18n) in git  
could be done, starting with the git-gui application (because I need  
that one in German to convince my workplace of switching to git).

Does this implementation look okay? If yes, I'd happily i18n'ize the  
rest of git-gui and provide a full German translation as well.

Thanks,

Christian Stimming





       
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's 
Comedy with an Edge to see what's on, when. 
http://tv.yahoo.com/collections/222

Re: [PATCH] Internationalization of git-gui

[Shawn O. Pearce]

Brett Schwarz <brett_schwarz@yahoo.com> wrote:
> This is a good idea. However, I assume the _ proc is just sugar. It
> might be better to follow a more "standard" way for this, and just
> import the msgcat namespace, and then you can just use [mc]. For
> example:
> 
> package require msgcat
> namespace import ::msgcat::*
>   .
>   .
>   .
> .mbar add cascade -label [mc Repository] -menu .mbar.repository

Not just better, I'd prefer it.  The proc name "_" is cute but
is just too darn short.  I would much prefer to use "mc" and just
say that "mc" in all of git-gui's namespaces is reserved for the
message catalog, much as "cb" is already reserved for setting up
callbacks for Tcl/Tk event handlers.

-- 
Shawn.

Re: [PATCH] Internationalization of git-gui

[Christian Stimming]

Quoting "Shawn O. Pearce" <spearce@spearce.org>:
> Brett Schwarz <brett_schwarz@yahoo.com> wrote:
>> This is a good idea. However, I assume the _ proc is just sugar. It
>> might be better to follow a more "standard" way for this, and just
>> import the msgcat namespace, and then you can just use [mc].
>>
>> package require msgcat
>> namespace import ::msgcat::*
>>   .
>>   .
>> .mbar add cascade -label [mc Repository] -menu .mbar.repository
>
> Not just better, I'd prefer it.  The proc name "_" is cute but
> is just too darn short.  I would much prefer to use "mc" and just
> say that "mc" in all of git-gui's namespaces is reserved for the
> message catalog

I used (and prefer) "_" because that's the standard function name for  
i18n'd strings when using gettext (talking about a "standard" way). In  
that case the convention from C simply carries over to tcl/tk, and  
programmers who have worked with gettext in C before, which uses  
_("some message"), directly apply what they already know. [mc ..], on  
the other hand, would be a tcl-only function name which doesn't give  
too much of a hint of what this function does, except for those  
programmers who happen to know that tcl's translation is done by a  
package called msgcat. One might rather consider something like [tr  
...], for "translate", or even [i18n ...].

That being said, I'm rather agnostic on which proc name you really  
prefer. Just pick one.

Being a newcomer on this list, could you please explain to me how to  
proceed with the i18n patches so far? Do you want to have patches  
submitted after some further changes (which ones?) and/or in different  
formats? Do you prefer to have all changes in a smaller number of  
commit rather than split the way I did before? Should I wait for some  
more days/weeks/whatever until you or particular other developers have  
reviewed the patches? Thanks.

Christian

Re: [PATCH] Internationalization of git-gui

[Shawn O. Pearce]

Christian Stimming <stimming@tuhh.de> wrote:
> I used (and prefer) "_" because that's the standard function name for  
> i18n'd strings when using gettext (talking about a "standard" way).

I thought about this today.  I almost want to use _, e.g:

  proc _ {args} {
    return [eval mc $args]
  }

For the translation, but I don't think its worth the CPU cycles in
Tcl to eval mc via _ every time we need a string when it only is
saving us one keystroke on a function name, *and* we are breaking
tradition with Tcl.

So when in Rome, wear a toga.  Or in this case, use [mc ...].

> Being a newcomer on this list, could you please explain to me how to  
> proceed with the i18n patches so far?

Sure.

> Do you want to have patches  
> submitted after some further changes (which ones?)

Yes.  Here's a few to get started with and that are really obvious.
Some I'm just asking for more information on.

 - Import msgcat::mc and use [mc] instead of [_].

 - Please combine the second and third patches into a single change.
 There is no reason to switch to [mc {}] only to switch to [mc ""].

 - Please use mc's formatting support, rather than [format].
 Its shorter code.

 - Don't bother trying to translate the strings "Tools" (for the
 Tools menu) or "Migrate" (for its only menu option).  This block
 of code doesn't even belong in git-gui.  Its for my day-job and
 is a custom hack that I need to strip out and carry as a local
 patch there, rather than in the public distribution.

 - In our Makefile we do the looping in GNU make using its
 $(foreach) operator, rather than using the shell's for builtin.
 In other words, can we have the catalog target look more like the
 install target?

 - Can ALL_LINGUAS be automatically built from the directory
 contents of the po/ directory?

 - Can we define a dist rule for the maintainer to build the catalog
 files, so the maintainer can convert the .po -> .msg for Tcl and
 the user doesn't need the GNU tools installed to build git-gui?


> and/or in different  
> formats?

Please send one patch per email message, inline and not attached.
This way they are easy to review, respond to and comment on.

> Do you prefer to have all changes in a smaller number of  
> commit rather than split the way I did before?

No, this series looks reasonably fine to me structurally.

Did you base the patches on git.git's git-gui/ subdirectory, or
did you base them on the git-gui.git repository?  Technically all
patches for git-gui should be against the git-gui repository on
repo.or.cz, as git-gui is its own project.  Periodic stable snapshots
are imported into git.git under the git-gui/ subdirectory, for the
ease of distribution with core git.

Dscho recently created a fork of git-gui.git here:

  http://repo.or.cz/w/git-gui/git-gui-i18n.git

and added your patch series into it.  But I'd like to see some
cleanups before it merges in, and I want to hold off on actually
applying it into git-gui 0.8.0 is released, which should be Real
Soon Now as I'm trying to make it into git 1.5.3, which is coming
Even Sooner Than I'd Hoped.  ;-)

> Should I wait for some  
> more days/weeks/whatever until you or particular other developers have  
> reviewed the patches? Thanks.

I think we're settled on using [mc].  I'm fine with the *.po ->
*.msg thing, especially if the maintainer can produce them and
package the *.msg files in the release tarball, so that the enduser
doesn't need to worry about msgfmt working.

-- 
Shawn.

Re: [PATCH] Internationalization of git-gui

[Christian Stimming]

Thanks for the detailed feedback.

Am Samstag, 21. Juli 2007 04:17 schrieb Shawn O. Pearce:
> Christian Stimming <stimming@tuhh.de> wrote:
> > I used (and prefer) "_" because that's the standard function name for
> > i18n'd strings when using gettext (talking about a "standard" way).
>
> but I don't think its worth the CPU cycles in
> Tcl to eval mc via _ every time we need a string when it only is
> saving us one keystroke on a function name, 

The actual lookup of the string in the translation catalog far outweighs the 
discussion of one extra function evaluation, but if that's what you prefer -

> *and* we are breaking  tradition with Tcl.
>
> So when in Rome, wear a toga.  Or in this case, use [mc ...].

Ok.

> > Do you want to have patches
> > submitted after some further changes (which ones?)
>
> Yes.  Here's a few to get started with and that are really obvious.
> Some I'm just asking for more information on.
>
>  - Import msgcat::mc and use [mc] instead of [_].

Will do.

>  - Please combine the second and third patches into a single change.
>  There is no reason to switch to [mc {}] only to switch to [mc ""].

Will do.

>  - Please use mc's formatting support, rather than [format].
>  Its shorter code.

Didn't know about that (you know, C gettext doesn't have that), and I'll have 
to check whether this might confuse xgettext on string extraction, but will 
probably be done.

>  - Don't bother trying to translate the strings "Tools" (for the
>  Tools menu) or "Migrate" (for its only menu option).  This block
>  of code doesn't even belong in git-gui.  Its for my day-job and
>  is a custom hack that I need to strip out and carry as a local
>  patch there, rather than in the public distribution.

Err... from looking at the code, it's not quite clear to me whether any code 
parts like these are not publicly shown to the user. For that reason I rather 
translated everything that was currently available in the file. But I'll 
happily remove this from the patch.

>  - In our Makefile we do the looping in GNU make using its
>  $(foreach) operator, rather than using the shell's for builtin.
>  In other words, can we have the catalog target look more like the
>  install target?

Sure. I did it this way because I'm more used to the shell syntax, but I'll 
change that.

>  - Can ALL_LINGUAS be automatically built from the directory
>  contents of the po/ directory?

Yes. I used this one because this variable always appears in gettext's 
autoconf infrastructure, but it's not required here. Will remove it.

>  - Can we define a dist rule for the maintainer to build the catalog
>  files, so the maintainer can convert the .po -> .msg for Tcl and
>  the user doesn't need the GNU tools installed to build git-gui?

Yes, I'll try to add that, but I'd need further feedback and testing whether 
it actually works.

> > and/or in different
> > formats?
>
> Please send one patch per email message, inline and not attached.
> This way they are easy to review, respond to and comment on.

I'll try to do that, but at the workplace where I work on this issue I'm 
forced to use a webmailer and I have to check whether this leaves the patches 
intact.

> > Do you prefer to have all changes in a smaller number of
> > commit rather than split the way I did before?
>
> No, this series looks reasonably fine to me structurally.
>
> Did you base the patches on git.git's git-gui/ subdirectory, 

Yes.

> or 
> did you base them on the git-gui.git repository?  Technically all
> patches for git-gui should be against the git-gui repository on
> repo.or.cz, as git-gui is its own project.  

Will do.

> Dscho recently created a fork of git-gui.git here:
>
>   http://repo.or.cz/w/git-gui/git-gui-i18n.git
>
> and added your patch series into it.  But I'd like to see some
> cleanups before it merges in, and I want to hold off on actually
> applying it into git-gui 0.8.0 is released, 

Was this meant to say "hold off until git-gui 0.8.0 is released"? Sure, no 
problem.

I'll submit an updated set of patches by beginning of next week. Thank you 
very much for the feedback.

Christian

Re: [PATCH] Internationalization of git-gui

[Shawn O. Pearce]

Christian Stimming <stimming@tuhh.de> wrote:
> Thanks for the detailed feedback.

Thanks for working on this!  Its something I knew we need to do,
but hadn't brought myself to do, because I speak English, and pretty
much only English.  Unless Tcl counts.  ;-)
 
> Am Samstag, 21. Juli 2007 04:17 schrieb Shawn O. Pearce:
> >
> > Please send one patch per email message, inline and not attached.
> > This way they are easy to review, respond to and comment on.
> 
> I'll try to do that, but at the workplace where I work on this issue I'm 
> forced to use a webmailer and I have to check whether this leaves the patches 
> intact.

Can you push to the mob branch on repo.or.cz?  Or setup your own
git-gui fork repository there?  Or someplace?  If so you can still
copy and paste the message into email for quick review and comment,
but I can actually pull the Git objects from a repository, and I
know Git won't corrupt things.
 
> > Dscho recently created a fork of git-gui.git here:
> >
> >   http://repo.or.cz/w/git-gui/git-gui-i18n.git
> >
> > and added your patch series into it.  But I'd like to see some
> > cleanups before it merges in, and I want to hold off on actually
> > applying it into git-gui 0.8.0 is released, 
> 
> Was this meant to say "hold off until git-gui 0.8.0 is released"? Sure, no 
> problem.

More or less.  I'm interested in this series, so I'm happy to get the
patches.  But I won't put them into 0.8.0, as I think it is too late
in the development period.  Especially for a build system change.
I've had too many bugs because of changes to the Makefile in prior
versions of git-gui.  But I am hoping that they will be among the
very first things applied after I tag 0.8.0 and start the 0.9.0
development cycle.  :-)
 
> I'll submit an updated set of patches by beginning of next week. Thank you 
> very much for the feedback.

Thanks.

-- 
Shawn.

Re: [PATCH 1/5] Internationalization of git-gui

[Christian Stimming]

>From 18d783abd85e074c302c5e7979dfb242b3c6c386 Mon Sep 17 00:00:00 2001
From: Christian Stimming <chs@ckiste.goetheallee>
Date: Sat, 21 Jul 2007 13:51:48 +0200
Subject: [PATCH] Initialize msgcat (gettext).

Use [mc ...] as function name for translating user messages.

Signed-off-by: Christian Stimming <stimming@tuhh.de>
---

This patch starts over from before the first i18n patch has been applied and 
takes into account all discussion with Shawn. Currently I don't quite know 
how to apply these patches to the "mob" branch because one would have
to first revert those patches from me that have been applied there... Thanks.

 git-gui.sh |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/git-gui.sh b/git-gui.sh
index c5ff7c8..0c5ca46 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -108,6 +108,12 @@ if {$idx ne {}} {
 }
 unset -nocomplain oguirel idx fd
 
+## Internationalization (i18n) through msgcat and gettext. See
+## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html
+package require msgcat
+::msgcat::mcload [file join $oguilib msgs]
+namespace import ::msgcat::mc
+
 ######################################################################
 ##
 ## read only globals
-- 
1.5.2

Re: [PATCH 2/5] Internationalization of git-gui

[Christian Stimming]

>From d2d2dde44790c3d239d69d7250e9949b6ff002c2 Mon Sep 17 00:00:00 2001
From: Christian Stimming <chs@ckiste.goetheallee>
Date: Sat, 21 Jul 2007 14:21:34 +0200
Subject: [PATCH] Mark strings for translation.

The procedure [mc ...] will translate the strings through msgcat.
Strings must be enclosed in quotes, not in braces, because otherwise
xgettext cannot extract them properly, although on the Tcl side both
delimiters would work fine.

Signed-off-by: Christian Stimming <stimming@tuhh.de>
---

Here I marked much more strings than in the previous patch, and as discussed
the procedure [mc ...] is used for translation. Actually I think this pretty much 
caught all occurrences of user-visible strings in *this* file; there will be many
more strings in all the other files, of course.

 git-gui.sh |  170 ++++++++++++++++++++++++++++++------------------------------
 1 files changed, 85 insertions(+), 85 deletions(-)

diff --git a/git-gui.sh b/git-gui.sh
index 0c5ca46..95dac55 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1653,18 +1653,18 @@ set ui_comm {}
 # -- Menu Bar
 #
 menu .mbar -tearoff 0
-.mbar add cascade -label Repository -menu .mbar.repository
-.mbar add cascade -label Edit -menu .mbar.edit
+.mbar add cascade -label [mc Repository] -menu .mbar.repository
+.mbar add cascade -label [mc Edit] -menu .mbar.edit
 if {[is_enabled branch]} {
-	.mbar add cascade -label Branch -menu .mbar.branch
+	.mbar add cascade -label [mc Branch] -menu .mbar.branch
 }
 if {[is_enabled multicommit] || [is_enabled singlecommit]} {
-	.mbar add cascade -label Commit -menu .mbar.commit
+	.mbar add cascade -label [mc Commit] -menu .mbar.commit
 }
 if {[is_enabled transport]} {
-	.mbar add cascade -label Merge -menu .mbar.merge
-	.mbar add cascade -label Fetch -menu .mbar.fetch
-	.mbar add cascade -label Push -menu .mbar.push
+	.mbar add cascade -label [mc Merge] -menu .mbar.merge
+	.mbar add cascade -label [mc Fetch] -menu .mbar.fetch
+	.mbar add cascade -label [mc Push] -menu .mbar.push
 }
 . configure -menu .mbar
 
@@ -1673,7 +1673,7 @@ if {[is_enabled transport]} {
 menu .mbar.repository
 
 .mbar.repository add command \
-	-label {Browse Current Branch's Files} \
+	-label [mc "Browse Current Branch's Files"] \
 	-command {browser::new $current_branch}
 trace add variable current_branch write ".mbar.repository entryconf [.mbar.repository index last] -label \"Browse \$current_branch's Files\" ;#"
 .mbar.repository add command \
@@ -1682,69 +1682,69 @@ trace add variable current_branch write ".mbar.repository entryconf [.mbar.repos
 .mbar.repository add separator
 
 .mbar.repository add command \
-	-label {Visualize Current Branch's History} \
+	-label [mc "Visualize Current Branch's History"] \
 	-command {do_gitk $current_branch}
 trace add variable current_branch write ".mbar.repository entryconf [.mbar.repository index last] -label \"Visualize \$current_branch's History\" ;#"
 .mbar.repository add command \
-	-label {Visualize All Branch History} \
+	-label [mc "Visualize All Branch History"] \
 	-command {do_gitk --all}
 .mbar.repository add separator
 
 if {[is_enabled multicommit]} {
-	.mbar.repository add command -label {Database Statistics} \
+	.mbar.repository add command -label [mc "Database Statistics"] \
 		-command do_stats
 
-	.mbar.repository add command -label {Compress Database} \
+	.mbar.repository add command -label [mc "Compress Database"] \
 		-command do_gc
 
-	.mbar.repository add command -label {Verify Database} \
+	.mbar.repository add command -label [mc "Verify Database"] \
 		-command do_fsck_objects
 
 	.mbar.repository add separator
 
 	if {[is_Cygwin]} {
 		.mbar.repository add command \
-			-label {Create Desktop Icon} \
+			-label [mc "Create Desktop Icon"] \
 			-command do_cygwin_shortcut
 	} elseif {[is_Windows]} {
 		.mbar.repository add command \
-			-label {Create Desktop Icon} \
+			-label [mc "Create Desktop Icon"] \
 			-command do_windows_shortcut
 	} elseif {[is_MacOSX]} {
 		.mbar.repository add command \
-			-label {Create Desktop Icon} \
+			-label [mc "Create Desktop Icon"] \
 			-command do_macosx_app
 	}
 }
 
-.mbar.repository add command -label Quit \
+.mbar.repository add command -label [mc Quit] \
 	-command do_quit \
 	-accelerator $M1T-Q
 
 # -- Edit Menu
 #
 menu .mbar.edit
-.mbar.edit add command -label Undo \
+.mbar.edit add command -label [mc Undo] \
 	-command {catch {[focus] edit undo}} \
 	-accelerator $M1T-Z
-.mbar.edit add command -label Redo \
+.mbar.edit add command -label [mc Redo] \
 	-command {catch {[focus] edit redo}} \
 	-accelerator $M1T-Y
 .mbar.edit add separator
-.mbar.edit add command -label Cut \
+.mbar.edit add command -label [mc Cut] \
 	-command {catch {tk_textCut [focus]}} \
 	-accelerator $M1T-X
-.mbar.edit add command -label Copy \
+.mbar.edit add command -label [mc Copy] \
 	-command {catch {tk_textCopy [focus]}} \
 	-accelerator $M1T-C
-.mbar.edit add command -label Paste \
+.mbar.edit add command -label [mc Paste] \
 	-command {catch {tk_textPaste [focus]; [focus] see insert}} \
 	-accelerator $M1T-V
-.mbar.edit add command -label Delete \
+.mbar.edit add command -label [mc Delete] \
 	-command {catch {[focus] delete sel.first sel.last}} \
 	-accelerator Del
 .mbar.edit add separator
-.mbar.edit add command -label {Select All} \
+.mbar.edit add command -label [mc "Select All"] \
 	-command {catch {[focus] tag add sel 0.0 end}} \
 	-accelerator $M1T-A
 
@@ -1753,29 +1753,29 @@ menu .mbar.edit
 if {[is_enabled branch]} {
 	menu .mbar.branch
 
-	.mbar.branch add command -label {Create...} \
+	.mbar.branch add command -label [mc "Create..."] \
 		-command branch_create::dialog \
 		-accelerator $M1T-N
 	lappend disable_on_lock [list .mbar.branch entryconf \
 		[.mbar.branch index last] -state]
 
-	.mbar.branch add command -label {Checkout...} \
+	.mbar.branch add command -label [mc "Checkout..."] \
 		-command branch_checkout::dialog \
 		-accelerator $M1T-O
 	lappend disable_on_lock [list .mbar.branch entryconf \
 		[.mbar.branch index last] -state]
 
-	.mbar.branch add command -label {Rename...} \
+	.mbar.branch add command -label [mc "Rename..."] \
 		-command branch_rename::dialog
 	lappend disable_on_lock [list .mbar.branch entryconf \
 		[.mbar.branch index last] -state]
 
-	.mbar.branch add command -label {Delete...} \
+	.mbar.branch add command -label [mc "Delete..."] \
 		-command branch_delete::dialog
 	lappend disable_on_lock [list .mbar.branch entryconf \
 		[.mbar.branch index last] -state]
 
-	.mbar.branch add command -label {Reset...} \
+	.mbar.branch add command -label [mc "Reset..."] \
 		-command merge::reset_hard
 	lappend disable_on_lock [list .mbar.branch entryconf \
 		[.mbar.branch index last] -state]
@@ -1787,7 +1787,7 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {
 	menu .mbar.commit
 
 	.mbar.commit add radiobutton \
-		-label {New Commit} \
+		-label [mc "New Commit"] \
 		-command do_select_commit_type \
 		-variable selected_commit_type \
 		-value new
@@ -1795,7 +1795,7 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {
 		[list .mbar.commit entryconf [.mbar.commit index last] -state]
 
 	.mbar.commit add radiobutton \
-		-label {Amend Last Commit} \
+		-label [mc "Amend Last Commit"] \
 		-command do_select_commit_type \
 		-variable selected_commit_type \
 		-value amend
@@ -1804,40 +1804,40 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {
 
 	.mbar.commit add separator
 
-	.mbar.commit add command -label Rescan \
+	.mbar.commit add command -label [mc Rescan] \
 		-command do_rescan \
 		-accelerator F5
 	lappend disable_on_lock \
 		[list .mbar.commit entryconf [.mbar.commit index last] -state]
 
-	.mbar.commit add command -label {Add To Commit} \
+	.mbar.commit add command -label [mc "Add To Commit"] \
 		-command do_add_selection
 	lappend disable_on_lock \
 		[list .mbar.commit entryconf [.mbar.commit index last] -state]
 
-	.mbar.commit add command -label {Add Existing To Commit} \
+	.mbar.commit add command -label [mc "Add Existing To Commit"] \
 		-command do_add_all \
 		-accelerator $M1T-I
 	lappend disable_on_lock \
 		[list .mbar.commit entryconf [.mbar.commit index last] -state]
 
-	.mbar.commit add command -label {Unstage From Commit} \
+	.mbar.commit add command -label [mc "Unstage From Commit"] \
 		-command do_unstage_selection
 	lappend disable_on_lock \
 		[list .mbar.commit entryconf [.mbar.commit index last] -state]
 
-	.mbar.commit add command -label {Revert Changes} \
+	.mbar.commit add command -label [mc "Revert Changes"] \
 		-command do_revert_selection
 	lappend disable_on_lock \
 		[list .mbar.commit entryconf [.mbar.commit index last] -state]
 
 	.mbar.commit add separator
 
-	.mbar.commit add command -label {Sign Off} \
+	.mbar.commit add command -label [mc "Sign Off"] \
 		-command do_signoff \
 		-accelerator $M1T-S
 
-	.mbar.commit add command -label Commit \
+	.mbar.commit add command -label [mc Commit] \
 		-command do_commit \
 		-accelerator $M1T-Return
 	lappend disable_on_lock \
@@ -1848,12 +1848,12 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {
 #
 if {[is_enabled branch]} {
 	menu .mbar.merge
-	.mbar.merge add command -label {Local Merge...} \
+	.mbar.merge add command -label [mc "Local Merge..."] \
 		-command merge::dialog \
 		-accelerator $M1T-M
 	lappend disable_on_lock \
 		[list .mbar.merge entryconf [.mbar.merge index last] -state]
-	.mbar.merge add command -label {Abort Merge...} \
+	.mbar.merge add command -label [mc "Abort Merge..."] \
 		-command merge::reset_hard
 	lappend disable_on_lock \
 		[list .mbar.merge entryconf [.mbar.merge index last] -state]
@@ -1865,28 +1865,28 @@ if {[is_enabled transport]} {
 	menu .mbar.fetch
 
 	menu .mbar.push
-	.mbar.push add command -label {Push...} \
+	.mbar.push add command -label [mc "Push..."] \
 		-command do_push_anywhere \
 		-accelerator $M1T-P
-	.mbar.push add command -label {Delete...} \
+	.mbar.push add command -label [mc "Delete..."] \
 		-command remote_branch_delete::dialog
 }
 
 if {[is_MacOSX]} {
 	# -- Apple Menu (Mac OS X only)
 	#
-	.mbar add cascade -label Apple -menu .mbar.apple
+	.mbar add cascade -label [mc Apple] -menu .mbar.apple
 	menu .mbar.apple
 
-	.mbar.apple add command -label "About [appname]" \
+	.mbar.apple add command -label [mc "About %s" appname] \
 		-command do_about
-	.mbar.apple add command -label "Options..." \
+	.mbar.apple add command -label [mc "Options..."] \
 		-command do_options
 } else {
 	# -- Edit Menu
 	#
 	.mbar.edit add separator
-	.mbar.edit add command -label {Options...} \
+	.mbar.edit add command -label [mc "Options..."] \
 		-command do_options
 
 	# -- Tools Menu
@@ -1921,11 +1921,11 @@ if {[is_MacOSX]} {
 
 # -- Help Menu
 #
-.mbar add cascade -label Help -menu .mbar.help
+.mbar add cascade -label [mc Help] -menu .mbar.help
 menu .mbar.help
 
 if {![is_MacOSX]} {
-	.mbar.help add command -label "About [appname]" \
+	.mbar.help add command -label [mc "About %s" appname] \
 		-command do_about
 }
 
@@ -1962,7 +1962,7 @@ if {[file isfile $doc_path]} {
 }
 
 if {$browser ne {}} {
-	.mbar.help add command -label {Online Documentation} \
+	.mbar.help add command -label [mc "Online Documentation"] \
 		-command [list exec $browser $doc_url &]
 }
 unset browser doc_path doc_url
@@ -2078,7 +2078,7 @@ frame .branch \
 	-borderwidth 1 \
 	-relief sunken
 label .branch.l1 \
-	-text {Current Branch:} \
+	-text [mc "Current Branch:"] \
 	-anchor w \
 	-justify left
 label .branch.cb \
@@ -2099,7 +2099,7 @@ pack .vpane -anchor n -side top -fill both -expand 1
 # -- Index File List
 #
 frame .vpane.files.index -height 100 -width 200
-label .vpane.files.index.title -text {Staged Changes (Will Be Committed)} \
+label .vpane.files.index.title -text [mc "Staged Changes (Will Be Committed)"] \
 	-background lightgreen
 text $ui_index -background white -borderwidth 0 \
 	-width 20 -height 10 \
@@ -2119,7 +2119,7 @@ pack $ui_index -side left -fill both -expand 1
 # -- Working Directory File List
 #
 frame .vpane.files.workdir -height 100 -width 200
-label .vpane.files.workdir.title -text {Unstaged Changes (Will Not Be Committed)} \
+label .vpane.files.workdir.title -text [mc "Unstaged Changes (Will Not Be Committed)"] \
 	-background lightsalmon
 text $ui_workdir -background white -borderwidth 0 \
 	-width 20 -height 10 \
@@ -2160,29 +2160,29 @@ label .vpane.lower.commarea.buttons.l -text {} \
 pack .vpane.lower.commarea.buttons.l -side top -fill x
 pack .vpane.lower.commarea.buttons -side left -fill y
 
-button .vpane.lower.commarea.buttons.rescan -text {Rescan} \
+button .vpane.lower.commarea.buttons.rescan -text [mc Rescan] \
 	-command do_rescan
 pack .vpane.lower.commarea.buttons.rescan -side top -fill x
 lappend disable_on_lock \
 	{.vpane.lower.commarea.buttons.rescan conf -state}
 
-button .vpane.lower.commarea.buttons.incall -text {Add Existing} \
+button .vpane.lower.commarea.buttons.incall -text [mc "Add Existing"] \
 	-command do_add_all
 pack .vpane.lower.commarea.buttons.incall -side top -fill x
 lappend disable_on_lock \
 	{.vpane.lower.commarea.buttons.incall conf -state}
 
-button .vpane.lower.commarea.buttons.signoff -text {Sign Off} \
+button .vpane.lower.commarea.buttons.signoff -text [mc "Sign Off"] \
 	-command do_signoff
 pack .vpane.lower.commarea.buttons.signoff -side top -fill x
 
-button .vpane.lower.commarea.buttons.commit -text {Commit} \
+button .vpane.lower.commarea.buttons.commit -text [mc Commit] \
 	-command do_commit
 pack .vpane.lower.commarea.buttons.commit -side top -fill x
 lappend disable_on_lock \
 	{.vpane.lower.commarea.buttons.commit conf -state}
 
-button .vpane.lower.commarea.buttons.push -text {Push} \
+button .vpane.lower.commarea.buttons.push -text [mc Push] \
 	-command do_push_anywhere
 pack .vpane.lower.commarea.buttons.push -side top -fill x
 
@@ -2193,14 +2193,14 @@ frame .vpane.lower.commarea.buffer.header
 set ui_comm .vpane.lower.commarea.buffer.t
 set ui_coml .vpane.lower.commarea.buffer.header.l
 radiobutton .vpane.lower.commarea.buffer.header.new \
-	-text {New Commit} \
+	-text [mc "New Commit"] \
 	-command do_select_commit_type \
 	-variable selected_commit_type \
 	-value new
 lappend disable_on_lock \
 	[list .vpane.lower.commarea.buffer.header.new conf -state]
 radiobutton .vpane.lower.commarea.buffer.header.amend \
-	-text {Amend Last Commit} \
+	-text [mc "Amend Last Commit"] \
 	-command do_select_commit_type \
 	-variable selected_commit_type \
 	-value amend
@@ -2212,12 +2212,12 @@ label $ui_coml \
 proc trace_commit_type {varname args} {
 	global ui_coml commit_type
 	switch -glob -- $commit_type {
-	initial       {set txt {Initial Commit Message:}}
-	amend         {set txt {Amended Commit Message:}}
-	amend-initial {set txt {Amended Initial Commit Message:}}
-	amend-merge   {set txt {Amended Merge Commit Message:}}
-	merge         {set txt {Merge Commit Message:}}
-	*             {set txt {Commit Message:}}
+	initial       {set txt [mc "Initial Commit Message:"]}
+	amend         {set txt [mc "Amended Commit Message:"]}
+	amend-initial {set txt [mc "Amended Initial Commit Message:"]}
+	amend-merge   {set txt [mc "Amended Merge Commit Message:"]}
+	merge         {set txt [mc "Merge Commit Message:"]}
+	*             {set txt [mc "Commit Message:"]}
 	}
 	$ui_coml conf -text $txt
 }
@@ -2246,23 +2246,23 @@ pack .vpane.lower.commarea.buffer -side left -fill y
 set ctxm .vpane.lower.commarea.buffer.ctxm
 menu $ctxm -tearoff 0
 $ctxm add command \
-	-label {Cut} \
+	-label [mc Cut] \
 	-command {tk_textCut $ui_comm}
 $ctxm add command \
-	-label {Copy} \
+	-label [mc Copy] \
 	-command {tk_textCopy $ui_comm}
 $ctxm add command \
-	-label {Paste} \
+	-label [mc Paste] \
 	-command {tk_textPaste $ui_comm}
 $ctxm add command \
-	-label {Delete} \
+	-label [mc Delete] \
 	-command {$ui_comm delete sel.first sel.last}
 $ctxm add separator
 $ctxm add command \
-	-label {Select All} \
+	-label [mc "Select All"] \
 	-command {focus $ui_comm;$ui_comm tag add sel 0.0 end}
 $ctxm add command \
-	-label {Copy All} \
+	-label [mc "Copy All"] \
 	-command {
 		$ui_comm tag add sel 0.0 end
 		tk_textCopy $ui_comm
@@ -2270,7 +2270,7 @@ $ctxm add command \
 	}
 $ctxm add separator
 $ctxm add command \
-	-label {Sign Off} \
+	-label [mc "Sign Off"] \
 	-command do_signoff
 bind_button3 $ui_comm "tk_popup $ctxm %X %Y"
 
@@ -2320,7 +2320,7 @@ pack .vpane.lower.diff.header.path -fill x
 set ctxm .vpane.lower.diff.header.ctxm
 menu $ctxm -tearoff 0
 $ctxm add command \
-	-label {Copy} \
+	-label [mc Copy] \
 	-command {
 		clipboard clear
 		clipboard append \
@@ -2388,19 +2388,19 @@ $ui_diff tag raise sel
 set ctxm .vpane.lower.diff.body.ctxm
 menu $ctxm -tearoff 0
 $ctxm add command \
-	-label {Refresh} \
+	-label [mc Refresh] \
 	-command reshow_diff
 lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
 $ctxm add command \
-	-label {Copy} \
+	-label [mc Copy] \
 	-command {tk_textCopy $ui_diff}
 lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
 $ctxm add command \
-	-label {Select All} \
+	-label [mc "Select All"] \
 	-command {focus $ui_diff;$ui_diff tag add sel 0.0 end}
 lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
 $ctxm add command \
-	-label {Copy All} \
+	-label [mc "Copy All"] \
 	-command {
 		$ui_diff tag add sel 0.0 end
 		tk_textCopy $ui_diff
@@ -2409,44 +2409,44 @@ $ctxm add command \
 lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
 $ctxm add separator
 $ctxm add command \
-	-label {Apply/Reverse Hunk} \
+	-label [mc "Apply/Reverse Hunk"] \
 	-command {apply_hunk $cursorX $cursorY}
 set ui_diff_applyhunk [$ctxm index last]
 lappend diff_actions [list $ctxm entryconf $ui_diff_applyhunk -state]
 $ctxm add separator
 $ctxm add command \
-	-label {Decrease Font Size} \
+	-label [mc "Decrease Font Size"] \
 	-command {incr_font_size font_diff -1}
 lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
 $ctxm add command \
-	-label {Increase Font Size} \
+	-label [mc "Increase Font Size"] \
 	-command {incr_font_size font_diff 1}
 lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
 $ctxm add separator
 $ctxm add command \
-	-label {Show Less Context} \
+	-label [mc "Show Less Context"] \
 	-command {if {$repo_config(gui.diffcontext) >= 1} {
 		incr repo_config(gui.diffcontext) -1
 		reshow_diff
 	}}
 lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
 $ctxm add command \
-	-label {Show More Context} \
+	-label [mc "Show More Context"] \
 	-command {if {$repo_config(gui.diffcontext) < 99} {
 		incr repo_config(gui.diffcontext)
 		reshow_diff
 	}}
 lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
 $ctxm add separator
-$ctxm add command -label {Options...} \
+$ctxm add command -label [mc "Options..."] \
 	-command do_options
 bind_button3 $ui_diff "
 	set cursorX %x
 	set cursorY %y
 	if {\$ui_index eq \$current_diff_side} {
-		$ctxm entryconf $ui_diff_applyhunk -label {Unstage Hunk From Commit}
+		$ctxm entryconf $ui_diff_applyhunk -label [mc {Unstage Hunk From Commit}]
 	} else {
-		$ctxm entryconf $ui_diff_applyhunk -label {Stage Hunk For Commit}
+		$ctxm entryconf $ui_diff_applyhunk -label [mc {Stage Hunk For Commit}]
 	}
 	tk_popup $ctxm %X %Y
 "
-- 
1.5.2

Re: [PATCH 3/5] Internationalization of git-gui

[Christian Stimming]

>From cf68c8b36399d46f63e417e99c6783411213a55a Mon Sep 17 00:00:00 2001
From: Christian Stimming <chs@ckiste.goetheallee>
Date: Sat, 21 Jul 2007 14:17:07 +0200
Subject: [PATCH] Makefile rules for translation catalog generation and installation.


Signed-off-by: Christian Stimming <stimming@tuhh.de>
---
As discussed I've replaced the shell for() by the GNU make foreach. Also, there 
isn't an ALL_LINGUAS variable anymore; we simply use all *.po files under po/.

 Makefile |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 1bac6fe..52975a7 100644
--- a/Makefile
+++ b/Makefile
@@ -103,6 +103,21 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
 $(GITGUI_BUILT_INS): git-gui
 	$(QUIET_BUILT_IN)rm -f $@ && ln git-gui $@
 
+XGETTEXT   ?= xgettext
+msgsdir    ?= $(libdir)/msgs
+msgsdir_SQ  = $(subst ','\'',$(msgsdir))
+PO_TEMPLATE = po/git-gui.pot
+ALL_POFILES = $(wildcard po/*.po)
+ALL_MSGFILES = $(subst .po,.msg,$(ALL_POFILES))
+
+$(PO_TEMPLATE): $(SCRIPT_SH) $(ALL_LIBFILES)
+	$(XGETTEXT) -kmc -LTcl -o $@ $(SCRIPT_SH) $(ALL_LIBFILES)
+update-po:: $(PO_TEMPLATE)
+	$(foreach p, $(ALL_POFILES), echo Updating $p ; msgmerge -U $p $(PO_TEMPLATE) )
+$(ALL_MSGFILES): %.msg : %.po
+	@echo Generating catalog $@
+	msgfmt --statistics --tcl $< -l $(basename $(notdir $<)) -d $(dir $@)
+
 lib/tclIndex: $(ALL_LIBFILES)
 	$(QUIET_INDEX)if echo \
 	  $(foreach p,$(PRELOAD_FILES),source $p\;) \
@@ -136,7 +151,7 @@ GIT-GUI-VARS: .FORCE-GIT-GUI-VARS
 		echo 1>$@ "$$VARS"; \
 	fi
 
-all:: $(ALL_PROGRAMS) lib/tclIndex
+all:: $(ALL_PROGRAMS) lib/tclIndex $(ALL_MSGFILES)
 
 install: all
 	$(QUIET)$(INSTALL_D0)'$(DESTDIR_SQ)$(gitexecdir_SQ)' $(INSTALL_D1)
@@ -145,6 +160,8 @@ install: all
 	$(QUIET)$(INSTALL_D0)'$(DESTDIR_SQ)$(libdir_SQ)' $(INSTALL_D1)
 	$(QUIET)$(INSTALL_R0)lib/tclIndex $(INSTALL_R1) '$(DESTDIR_SQ)$(libdir_SQ)'
 	$(QUIET)$(foreach p,$(ALL_LIBFILES), $(INSTALL_R0)$p $(INSTALL_R1) '$(DESTDIR_SQ)$(libdir_SQ)' &&) true
+	$(QUIET)$(INSTALL_D0)'$(DESTDIR_SQ)$(msgsdir_SQ)' $(INSTALL_D1)
+	$(QUIET)$(foreach p,$(ALL_MSGFILES), $(INSTALL_R0)$p $(INSTALL_R1) '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
 
 dist-version:
 	@mkdir -p $(TARDIR)
-- 
1.5.2

Re: [PATCH 3/5] Internationalization of git-gui

[Christian Stimming]

From 37241c4142c6bfe18e94a1891dbf1a9d1ee2953d Mon Sep 17 00:00:00 2001
From: Christian Stimming <chs@ckiste.goetheallee>
Date: Sat, 21 Jul 2007 14:18:14 +0200
Subject: [PATCH] Initial German translation for testing of i18n.


Signed-off-by: Christian Stimming <stimming@tuhh.de>
---
And a new German translation, so far 100% but many more strings are to come.

 po/de.po |  265 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 265 insertions(+), 0 deletions(-)
 create mode 100644 po/de.po

diff --git a/po/de.po b/po/de.po
new file mode 100644
index 0000000..0592836
--- /dev/null
+++ b/po/de.po
@@ -0,0 +1,265 @@
+# Translation of git-gui to German.
+# Copyright (C) 2007 Linux Torvalds
+# This file is distributed under the same license as the git package.
+# Christian Stimming <stimming@tuhh.de>, 2007
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: git-gui\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2007-07-19 15:10+0200\n"
+"PO-Revision-Date: 2007-07-19 15:11+0200\n"
+"Last-Translator: Christian Stimming <stimming@tuhh.de>\n"
+"Language-Team: German\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: git-gui.sh:1621
+msgid "Repository"
+msgstr "Projektarchiv"
+
+#: git-gui.sh:1622
+msgid "Edit"
+msgstr "Bearbeiten"
+
+#: git-gui.sh:1624
+msgid "Branch"
+msgstr "Zweig"
+
+#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134
+msgid "Commit"
+msgstr "Übertragen"
+
+#: git-gui.sh:1630
+msgid "Merge"
+msgstr "Zusammenführen"
+
+#: git-gui.sh:1631
+msgid "Fetch"
+msgstr "Holen"
+
+#: git-gui.sh:1632 git-gui.sh:2140
+msgid "Push"
+msgstr "Schieben"
+
+#: git-gui.sh:1641
+msgid "Browse Current Branch"
+msgstr "Aktuellen Zweig durchblättern"
+
+#: git-gui.sh:1647
+msgid "Visualize Current Branch"
+msgstr "Aktuellen Zweig darstellen"
+
+#: git-gui.sh:1651
+msgid "Visualize All Branches"
+msgstr "Alle Zweige darstellen"
+
+#: git-gui.sh:1656
+msgid "Database Statistics"
+msgstr "Datenbankstatistik"
+
+#: git-gui.sh:1659
+msgid "Compress Database"
+msgstr "Datenbank komprimieren"
+
+#: git-gui.sh:1662
+msgid "Verify Database"
+msgstr "Datenbank prüfen"
+
+#: git-gui.sh:1669 git-gui.sh:1673 git-gui.sh:1677
+msgid "Create Desktop Icon"
+msgstr "Desktop-Icon erstellen"
+
+#: git-gui.sh:1682
+msgid "Quit"
+msgstr "Beenden"
+
+#: git-gui.sh:1689
+msgid "Undo"
+msgstr "Rückgängig"
+
+#: git-gui.sh:1692
+msgid "Redo"
+msgstr "Wiederholen"
+
+#: git-gui.sh:1696 git-gui.sh:2204
+msgid "Cut"
+msgstr "Ausschneiden"
+
+#: git-gui.sh:1699 git-gui.sh:2207 git-gui.sh:2278 git-gui.sh:2350
+msgid "Copy"
+msgstr "Kopieren"
+
+#: git-gui.sh:1702 git-gui.sh:2210
+msgid "Paste"
+msgstr "Einfügen"
+
+#: git-gui.sh:1705 git-gui.sh:2213
+msgid "Delete"
+msgstr "Löschen"
+
+#: git-gui.sh:1709 git-gui.sh:2217 git-gui.sh:2354
+msgid "Select All"
+msgstr "Alle auswählen"
+
+#: git-gui.sh:1718
+msgid "Create..."
+msgstr "Erstellen..."
+
+#: git-gui.sh:1724
+msgid "Checkout..."
+msgstr "Auschecken..."
+
+#: git-gui.sh:1730
+msgid "Rename..."
+msgstr "Umbenennen..."
+
+#: git-gui.sh:1735 git-gui.sh:1833
+msgid "Delete..."
+msgstr "Löschen..."
+
+#: git-gui.sh:1740
+msgid "Reset..."
+msgstr "Zurücksetzen..."
+
+#: git-gui.sh:1752 git-gui.sh:2151
+msgid "New Commit"
+msgstr "Neu übertragen"
+
+#: git-gui.sh:1760 git-gui.sh:2158
+msgid "Amend Last Commit"
+msgstr "Letzte Übertragung ergänzen"
+
+#: git-gui.sh:1769 git-gui.sh:2118
+msgid "Rescan"
+msgstr "Neu laden"
+
+#: git-gui.sh:1775
+msgid "Add To Commit"
+msgstr "Zur Bereitstellung hinzufügen"
+
+#: git-gui.sh:1780
+msgid "Add Existing To Commit"
+msgstr "Existierendes zur Bereitstellung hinzufügen"
+
+#: git-gui.sh:1786
+msgid "Unstage From Commit"
+msgstr "Aus der Bereitstellung herausnehmen"
+
+#: git-gui.sh:1791
+msgid "Revert Changes"
+msgstr "Änderungen verwerfen"
+
+#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228
+msgid "Sign Off"
+msgstr "Freizeichnen"
+
+#: git-gui.sh:1813
+msgid "Local Merge..."
+msgstr "Lokales Zusammenführen..."
+
+#: git-gui.sh:1817
+msgid "Abort Merge..."
+msgstr "Zusammenführen abbrechen..."
+
+#: git-gui.sh:1830
+msgid "Push..."
+msgstr "Schieben..."
+
+#: git-gui.sh:1840
+msgid "Apple"
+msgstr "Apple"
+
+#: git-gui.sh:1843 git-gui.sh:1888
+#, tcl-format
+msgid "About %s"
+msgstr "Über %s"
+
+#: git-gui.sh:1845 git-gui.sh:1851 git-gui.sh:2396
+msgid "Options..."
+msgstr "Optionen..."
+
+#: git-gui.sh:1873
+msgid "Tools"
+msgstr "Werkzeuge"
+
+#: git-gui.sh:1875
+msgid "Migrate"
+msgstr "Migrieren"
+
+#: git-gui.sh:1884
+msgid "Help"
+msgstr "Hilfe"
+
+#: git-gui.sh:1925
+msgid "Online Documentation"
+msgstr "Online-Dokumentation"
+
+#: git-gui.sh:2036
+msgid "Current Branch:"
+msgstr "Aktueller Zweig:"
+
+#: git-gui.sh:2057
+msgid "Staged Changes (Will Be Committed)"
+msgstr "Bereitgestellte Änderungen (werden übertragen)"
+
+#: git-gui.sh:2077
+msgid "Unstaged Changes (Will Not Be Committed)"
+msgstr "Nicht bereitgestellte Änderungen (werden nicht übertragen)"
+
+#: git-gui.sh:2124
+msgid "Add Existing"
+msgstr "Existierendes hinzufügen"
+
+#: git-gui.sh:2170
+msgid "Initial Commit Message:"
+msgstr "Erstmalige Übertragungsmeldung"
+
+#: git-gui.sh:2171
+msgid "Amended Commit Message:"
+msgstr "Zur Übertragungsmeldung hinzufügen:"
+
+#: git-gui.sh:2172
+msgid "Amended Initial Commit Message:"
+msgstr "Zur erstmaligen Übertragungsmeldung hinzufügen:"
+
+#: git-gui.sh:2173
+msgid "Amended Merge Commit Message:"
+msgstr "Zur Zusammenführungs-Übertragungsmeldung hinzufügen:"
+
+#: git-gui.sh:2174
+msgid "Merge Commit Message:"
+msgstr "Übertragungsmeldung Zusammenführung:"
+
+#: git-gui.sh:2175
+msgid "Commit Message:"
+msgstr "Übertragungsmeldung:"
+
+#: git-gui.sh:2220 git-gui.sh:2358
+msgid "Copy All"
+msgstr "Alle kopieren"
+
+#: git-gui.sh:2346
+msgid "Refresh"
+msgstr "Aktualisieren"
+
+#: git-gui.sh:2367
+msgid "Apply/Reverse Hunk"
+msgstr "Änderung anwenden/umkehren"
+
+#: git-gui.sh:2373
+msgid "Decrease Font Size"
+msgstr "Schriftgröße verkleinern"
+
+#: git-gui.sh:2377
+msgid "Increase Font Size"
+msgstr "Schriftgröße vergrößern"
+
+#: git-gui.sh:2382
+msgid "Show Less Context"
+msgstr "Weniger Kontext anzeigen"
+
+#: git-gui.sh:2389
+msgid "Show More Context"
+msgstr "Mehr Kontext anzeigen"
-- 
1.5.2

Re: [PATCH 5/5] Internationalization of git-gui

[Christian Stimming]

From f074190d3bf1c08cd833afaa7ba42731b1e7f572 Mon Sep 17 00:00:00 2001
From: Christian Stimming <stimming@tuhh.de>
Date: Sat, 21 Jul 2007 14:39:24 +0200
Subject: [PATCH] Add glossary to ensure consistent translations.


Signed-off-by: Christian Stimming <stimming@tuhh.de>
---
And last but not least an initial list of the most important terms throughout git 
and git-gui; out of convenience I've already included my decisions on German 
translation wordings but in the future those translations will probably be collected 
elsewhere.

 po/glossary.csv |   24 ++++++++++++++++++++++++
 1 files changed, 24 insertions(+), 0 deletions(-)
 create mode 100644 po/glossary.csv

diff --git a/po/glossary.csv b/po/glossary.csv
new file mode 100644
index 0000000..e6ffe46
--- /dev/null
+++ b/po/glossary.csv
@@ -0,0 +1,24 @@
+"English Term"	"de translation"
+"amend"	"ergänzen"
+"annotate"	"annotieren"
+"branch"	"Zweig, verzweigen"
+"checkout"	"Auschecken"
+"commit"	"übertragen (senden?, übergeben?)"
+"diff"	"vergleichen"
+"fetch"	"holen"
+"merge"	"zusammenführen"
+"message"	"Meldung"
+"pull"	"ziehen (übernehmen?)"
+"push"	"schieben (hochladen? verschicken?)"
+"redo"	"Wiederholen"
+"repository"	"Projektarchiv"
+"reset"	"Zurücksetzen"
+"revert"	"zurückkehren"
+"revision"	"Revision"
+"sign off"	"freizeichnen"
+"staging area"	"Bereitstellung"
+"status"	"Status"
+"tag"	"Markierung, markieren"
+"undo"	"Rückgängig"
+"update"	"aktualisieren"
+"working copy"	"Arbeitskopie"
-- 
1.5.2

Re: [PATCH 3/5] Internationalization of git-gui

[David Kastrup]

Christian Stimming <stimming@tuhh.de> writes:

> And a new German translation, so far 100% but many more strings are to come.
>
>  po/de.po |  265 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 265 insertions(+), 0 deletions(-)
>  create mode 100644 po/de.po

I have somewhat different proposals which sound less awkward, I
think.  Of course, it is always a matter of taste whether a technical
term should really be translated always, but assuming that, I'll make
some German proposals.  Some may be tongue in cheek.

> +#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134
> +msgid "Commit"
> +msgstr "Übertragen"

Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein
passendes Substantiv zu finden.  "Sendung"?

> +#: git-gui.sh:1631
> +msgid "Fetch"
> +msgstr "Holen"

Importieren (hauptsächlich, weil es zu Exportieren paßt und Schieben
häßlich ist)

> +#: git-gui.sh:1632 git-gui.sh:2140
> +msgid "Push"
> +msgstr "Schieben"

Exportieren

> +#: git-gui.sh:1641
> +msgid "Browse Current Branch"
> +msgstr "Aktuellen Zweig durchblättern"

Im aktuellen Zweig stöbern.

> +#: git-gui.sh:1659
> +msgid "Compress Database"
> +msgstr "Datenbank komprimieren"

Ganz Deutsch: verdichten.

> +
> +#: git-gui.sh:1662
> +msgid "Verify Database"
> +msgstr "Datenbank prüfen"

überprüfen (prüfen wäre eher zu "checking")

> +#: git-gui.sh:1669 git-gui.sh:1673 git-gui.sh:1677
> +msgid "Create Desktop Icon"
> +msgstr "Desktop-Icon erstellen"

Da gibt es sicher einen neudeutschen Ausdruck, aber als
Nichtwindowsnutzer mit Amilokale...

> +#: git-gui.sh:1689
> +msgid "Undo"
> +msgstr "Rückgängig"

Ach nein.

> +#: git-gui.sh:1692
> +msgid "Redo"
> +msgstr "Wiederholen"

Jetzt doch.

> +#: git-gui.sh:1709 git-gui.sh:2217 git-gui.sh:2354
> +msgid "Select All"
> +msgstr "Alle auswählen"

Alles auswählen zöge ich vor.

> +#: git-gui.sh:1724
> +msgid "Checkout..."
> +msgstr "Auschecken..."

Ausspielung.

> +#: git-gui.sh:1752 git-gui.sh:2151
> +msgid "New Commit"
> +msgstr "Neu übertragen"

Neue Sendung

> +#: git-gui.sh:1760 git-gui.sh:2158
> +msgid "Amend Last Commit"
> +msgstr "Letzte Übertragung ergänzen"

Letzte Sendung korrigieren.

> +#: git-gui.sh:1775
> +msgid "Add To Commit"
> +msgstr "Zur Bereitstellung hinzufügen"

Der Sendung hinzufügen.

> +#: git-gui.sh:1780
> +msgid "Add Existing To Commit"
> +msgstr "Existierendes zur Bereitstellung hinzufügen"

Der Sendung hinzufügen.

> +#: git-gui.sh:1786
> +msgid "Unstage From Commit"
> +msgstr "Aus der Bereitstellung herausnehmen"

Aus der Sendung entfernen.

> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228
> +msgid "Sign Off"
> +msgstr "Freizeichnen"

Gegenzeichnen?

> +#: git-gui.sh:2057
> +msgid "Staged Changes (Will Be Committed)"
> +msgstr "Bereitgestellte Änderungen (werden übertragen)"

Einzupflegende Änderungen

> +#: git-gui.sh:2077
> +msgid "Unstaged Changes (Will Not Be Committed)"
> +msgstr "Nicht bereitgestellte Änderungen (werden nicht übertragen)"

Nicht einzupflegende Änderungen

So, jetzt geht mir die Luft aus.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [PATCH 3/5] Internationalization of git-gui

[Simon 'corecode' Schubert]

David Kastrup wrote:
>> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228
>> +msgid "Sign Off"
>> +msgstr "Freizeichnen"
> 
> Gegenzeichnen?

Abzeichnen!

Re: [PATCH 3/5] Internationalization of git-gui

[David Kastrup]

Simon 'corecode' Schubert <corecode@fs.ei.tum.de> writes:

> David Kastrup wrote:
>>> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228
>>> +msgid "Sign Off"
>>> +msgstr "Freizeichnen"
>>
>> Gegenzeichnen?
>
> Abzeichnen!

Absegnen.  Ich denke mal, in der Form mit "Ab" ist das dermaßen
gebräuchlich, daß man damit keine religiösen Befindlichkeiten
verletzt.

Ansonsten: Abnicken oder Gutheißen.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Translation process (was: [PATCH 3/5] Internationalization of git-gui)

[Christian Stimming]

Am Samstag, 21. Juli 2007 15:46 schrieb David Kastrup:
> Christian Stimming <stimming@tuhh.de> writes:
> > And a new German translation, so far 100% but many more strings are to
> > come.
>
> I have somewhat different proposals which sound less awkward, I
> think.  Of course, it is always a matter of taste whether a technical
> term should really be translated always, but assuming that, I'll make
> some German proposals.  Some may be tongue in cheek.

Thanks for the suggestions. However, I don't think it is of much worth to 
discuss individual message translations *right now*; instead, here's what I 
would propose instead:

The most difficult issue in a program translation is to find good translation 
wordings for those key words which are used each and every time throughout 
the program. Once you've decided on a particular translation for each of 
these words, the rest is just grunt work. So the important part is to 
translate these key words. Incidentally, I've added the file po/glossary.cvs 
for exactly this purpose. In there you find my current collection of key 
words that occur throughout git-gui (and git, for that matter), including a 
set of proposed translations to German language. This should be the place 
where the keyword translations should be discussed first. The discussion of 
the actual translations should be deferred until after the glossary 
translations have been discussed and agreed upon.

(I'm unsure whether the translations should be kept in the same glossary file; 
in the glossary for the gnucash project [1] we've actually added an extra 
directory and encourage translators to add an extra po file for their 
glossary translations. However, the glossary of gnucash has more than 150 
terms and many of them require to be defined clearly as well, as translators 
would otherwise be unable to translate them concisely. In git-gui, the 
glossary is 25 terms so far and I think the git documentation already 
contains enough definitions of all of them. Nevertheless, maybe it would make 
a better structure if the translations of the glossary are kept in a separate 
po file for each language. Hm.)

In short: Please discuss the glossary first, and not the actual de.po message 
file. Once the glossary has been decided upon, the de.po will be adapted, and 
*after that* a discussion of de.po makes sense. But not before that.

Regards,

Christian

[1] 
http://svn.gnucash.org/trac/browser/gnucash/trunk/po/glossary/gnc-glossary.txt

Re: German translations (was: [PATCH 3/5] Internationalization of git-gui)

[Christian Stimming]

Am Samstag, 21. Juli 2007 15:46 schrieb David Kastrup:
> Christian Stimming <stimming@tuhh.de> writes:
> > And a new German translation, so far 100% but many more strings are to
> > come.
>
> I have somewhat different proposals which sound less awkward, I
> think.  Of course, it is always a matter of taste whether a technical
> term should really be translated always, but assuming that, I'll make
> some German proposals.  Some may be tongue in cheek.

Thanks for additional word proposals. I'll discuss these and the two followups 
in German below.

> > +#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134
> > +msgid "Commit"
> > +msgstr "Übertragen"
>
> Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein
> passendes Substantiv zu finden.  "Sendung"?

Richtig - eine Kombination Substantiv/Verb wird benötigt. Ich habe im 
Glossar "übertragen (senden?, übergeben?)". Ersteres wird bei TortoiseSVN 
benutzt. Im Prinzip gehen die anderen auch; bei "Sendung"/"senden" befürchte 
ich aber zu viele Mehrdeutigkeiten, wenn man z.B. davon redet. den commit 
über TCP wohin senden will. Die Sendung wohin senden? Andererseits hat man 
bei Übertragung das gleiche Problem.

> > +#: git-gui.sh:1631
> > +msgid "Fetch"
> > +msgstr "Holen"
>
> Importieren (hauptsächlich, weil es zu Exportieren paßt und Schieben
> häßlich ist)

Importieren ist bereits für "git-{cvs,svn}import" reserviert, kann also hier 
nicht verwendet werden. Deswegen wird was anderes benötigt. Für fetch und 
pull gleichermaßen würden holen/ziehen/übernehmen gehen und man muss sich 
halt auf eine Zuordnung festlegen.

> > +#: git-gui.sh:1632 git-gui.sh:2140
> > +msgid "Push"
> > +msgstr "Schieben"
>
> Exportieren

Dito - bereits reserviert für git-cvsexport u.ä., also hier nicht benutzbar. 
Deswegen momentan dieses, ich bin aber auch nicht glücklich damit. Siehe 
Glossar: "schieben (hochladen? verschicken?)"

> > +#: git-gui.sh:1641
> > +msgid "Browse Current Branch"
> > +msgstr "Aktuellen Zweig durchblättern"
>
> Im aktuellen Zweig stöbern.

stöbern für "to browse"? Das ist aber definitiv nicht das, was normalerweise 
als Übersetzung von "to browse" gewählt wird. Da ist man eben bei blättern. 
Außerdem ist "stöbern" hart an der Grenze zur Flapsigkeit, die man (im 
Gegensatz zum engl. Original) bei deutscher Software unbedingt vermeiden 
muss.

> > +#: git-gui.sh:1659
> > +msgid "Compress Database"
> > +msgstr "Datenbank komprimieren"
>
> Ganz Deutsch: verdichten.

Alle E-Mail-Programme reden aber bereits von komprimieren (was in den Motoren 
schon immer ein deutscher Begriff war), so dass ich hier auch dabei bleiben 
würde.

> > +#: git-gui.sh:1662
> > +msgid "Verify Database"
> > +msgstr "Datenbank prüfen"
>
> überprüfen (prüfen wäre eher zu "checking")

"to verify" -> überprüfen? Ok.

> > +#: git-gui.sh:1709 git-gui.sh:2217 git-gui.sh:2354
> > +msgid "Select All"
> > +msgstr "Alle auswählen"
>
> Alles auswählen zöge ich vor.

Kommt auf den Kontext an - was soll denn ausgewählt werden? "Alle Sendungen" 
oder "Alles, was sichtbar ist"...

> > +#: git-gui.sh:1724
> > +msgid "Checkout..."
> > +msgstr "Auschecken..."
>
> Ausspielung.

Äh... nein. Auschecken ist auch nicht so toll (auch hier übernommen von 
TortoiseSVN), aber was besseres hab ich noch nicht gefunden.

> > +#: git-gui.sh:2057
> > +msgid "Staged Changes (Will Be Committed)"
> > +msgstr "Bereitgestellte Änderungen (werden übertragen)"
>
> Einzupflegende Änderungen

Nein, hier muss irgendwie die "staging area" mit auftauchen, denn so lautet 
die Beschriftung der linken Listbox. Da ich die mit "Bereitstellung" gewählt 
habe, muss das Wort hier wieder auftauchen. 

> > David Kastrup wrote:
> >>> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228
> >>> +msgid "Sign Off"
> >>> +msgstr "Freizeichnen"
> >>
> >> Gegenzeichnen?
> >
> > Abzeichnen!
>
> Absegnen.  Ich denke mal, in der Form mit "Ab" ist das dermaßen
> gebräuchlich, daß man damit keine religiösen Befindlichkeiten
> verletzt.
>
> Ansonsten: Abnicken oder Gutheißen.

Absegnen ist zu flapsig, Abnicken und Gutheißen erst recht. Gegenzeichnen 
lässt nicht erahnen, dass man seine eigenen commits ja auch "sign off" soll 
(wie z.B. in git.git/Documents/SubmittingPatches erklärt).  Abzeichnen wäre 
okay, aber das ist Freizeichnen auch.

Gruß

Christian

Re: German translations

[David Kastrup]

Christian Stimming <stimming@tuhh.de> writes:

> Am Samstag, 21. Juli 2007 15:46 schrieb David Kastrup:
>> Christian Stimming <stimming@tuhh.de> writes:
>> > And a new German translation, so far 100% but many more strings are to
>> > come.
>>
>> I have somewhat different proposals which sound less awkward, I
>> think.  Of course, it is always a matter of taste whether a technical
>> term should really be translated always, but assuming that, I'll make
>> some German proposals.  Some may be tongue in cheek.
>
> Thanks for additional word proposals. I'll discuss these and the two
> followups in German below.
>
>> > +#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134
>> > +msgid "Commit"
>> > +msgstr "Übertragen"
>>
>> Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein
>> passendes Substantiv zu finden.  "Sendung"?
>
> Richtig - eine Kombination Substantiv/Verb wird benötigt. Ich habe im 
> Glossar "übertragen (senden?, übergeben?)". Ersteres wird bei TortoiseSVN 
> benutzt. Im Prinzip gehen die anderen auch; bei "Sendung"/"senden" befürchte 
> ich aber zu viele Mehrdeutigkeiten, wenn man z.B. davon redet. den commit 
> über TCP wohin senden will. Die Sendung wohin senden? Andererseits hat man 
> bei Übertragung das gleiche Problem.

Ich habe was: Einspielen, Ausspielen, Einspielung, Ausspielung.
Symmetrisch, verständlich, als Verb und Substantiv zu gebrauchen.

>> > +#: git-gui.sh:1631
>> > +msgid "Fetch"
>> > +msgstr "Holen"
>>
>> Importieren (hauptsächlich, weil es zu Exportieren paßt und Schieben
>> häßlich ist)
>
> Importieren ist bereits für "git-{cvs,svn}import" reserviert, kann
> also hier nicht verwendet werden.

Ok.

> Deswegen wird was anderes benötigt. Für fetch und pull gleichermaßen
> würden holen/ziehen/übernehmen gehen und man muss sich halt auf eine
> Zuordnung festlegen.

fetch = anfordern, pull = übernehmen?

>> > +#: git-gui.sh:1632 git-gui.sh:2140
>> > +msgid "Push"
>> > +msgstr "Schieben"
>>
>> Exportieren
>
> Dito - bereits reserviert für git-cvsexport u.ä., also hier nicht
> benutzbar.  Deswegen momentan dieses, ich bin aber auch nicht
> glücklich damit. Siehe Glossar: "schieben (hochladen? verschicken?)"

Ausliefern?  Durchgeben?

>> > +#: git-gui.sh:1641
>> > +msgid "Browse Current Branch"
>> > +msgstr "Aktuellen Zweig durchblättern"
>>
>> Im aktuellen Zweig stöbern.
>
> stöbern für "to browse"? Das ist aber definitiv nicht das, was
> normalerweise als Übersetzung von "to browse" gewählt wird. Da ist
> man eben bei blättern.

Aber das wäre "leafing through" und ist eben auf Bücher beschränkt.

> Außerdem ist "stöbern" hart an der Grenze zur Flapsigkeit, die man
> (im Gegensatz zum engl. Original) bei deutscher Software unbedingt
> vermeiden muss.

Finde ich nicht, aber bei Interfaces ist natürlich die
Mehrheitsmeinung ausschlaggebend.  "wühlen" wäre flapsig.  Etwas
hochsprachlicher wäre noch "durchforsten", aber das trägt uns
natürlich den Zorn der Förster für den Begriffsmißbrauch zu.
"erkunden" wäre auch noch möglich.

>> > +#: git-gui.sh:2057
>> > +msgid "Staged Changes (Will Be Committed)"
>> > +msgstr "Bereitgestellte Änderungen (werden übertragen)"
>>
>> Einzupflegende Änderungen
>
> Nein, hier muss irgendwie die "staging area" mit auftauchen, denn so
> lautet die Beschriftung der linken Listbox. Da ich die mit
> "Bereitstellung" gewählt habe, muss das Wort hier wieder auftauchen.

Sehe ich zwar nicht so.

>> > David Kastrup wrote:
>> >>> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228
>> >>> +msgid "Sign Off"
>> >>> +msgstr "Freizeichnen"
>> >>
>> >> Gegenzeichnen?
>> >
>> > Abzeichnen!
>>
>> Absegnen.  Ich denke mal, in der Form mit "Ab" ist das dermaßen
>> gebräuchlich, daß man damit keine religiösen Befindlichkeiten
>> verletzt.
>>
>> Ansonsten: Abnicken oder Gutheißen.
>
> Absegnen ist zu flapsig, Abnicken und Gutheißen erst recht.

Abnicken ja, aber Gutheißen ist nun wirklich ein hochsprachlicher
Begriff.

>  Abzeichnen wäre okay, aber das ist Freizeichnen auch.

Freizeichnen ist viel zu nischensprachlich.  Mit Abzeichnen könnte ich
leben, obwohl ich Gutheißen besser fände.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: German translations

[Christian Stimming]

Am Samstag, 21. Juli 2007 21:57 schrieb David Kastrup:
> > Thanks for additional word proposals. I'll discuss these and the two
> > followups in German below.
> >
> >> > +#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134
> >> > +msgid "Commit"
> >> > +msgstr "Übertragen"
> >>
> >> Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein
> >> passendes Substantiv zu finden.  "Sendung"?
> >
> > Ich habe im Glossar "übertragen (senden?, übergeben?)". .
>
> Ich habe was: Einspielen, Ausspielen, Einspielung, Ausspielung.
> Symmetrisch, verständlich, als Verb und Substantiv zu gebrauchen.

Einspielen und Einspielung sind auch Möglichkeiten, aber bisher finde ich das 
noch nicht überzeugender als die Übertragung. 

Für was ist Ausspielung gemeint? Checkout? Für mich klingt 
ausspielen/Ausspielung hauptsächlich nach einer Pokerrunde (oder eher 
destruktiv, "dieser Mitarbeiter hat im Projekt wirklich ausgespielt") und 
nicht nach dem Ablegen in Akten oder dem Rüberschicken zum Archiv-Server. 
Aber stimmt, "checkout" braucht noch einen Begriff und bisher habe ich auch 
keinen überzeugenden Vorschlag.

> > Deswegen wird was anderes benötigt. Für fetch und pull gleichermaßen
> > würden holen/ziehen/übernehmen gehen und man muss sich halt auf eine
> > Zuordnung festlegen.
>
> fetch = anfordern, pull = übernehmen?

Klingt gut, ok, vielen Dank.

> >> > +#: git-gui.sh:1632 git-gui.sh:2140
> >> > +msgid "Push"
> >> > +msgstr "Schieben"
> >
> > Glossar: "schieben (hochladen? verschicken?)"
>
> Ausliefern?  Durchgeben?

Ausliefern ist gut, danke.

> >> > +#: git-gui.sh:1641
> >> > +msgid "Browse Current Branch"
> >> > +msgstr "Aktuellen Zweig durchblättern"
> >>
> >> Im aktuellen Zweig stöbern.
> >
> > stöbern für "to browse"? Das ist aber definitiv nicht das, was
> > normalerweise als Übersetzung von "to browse" gewählt wird. Da ist
> > man eben bei blättern.
>
> Aber das wäre "leafing through" und ist eben auf Bücher beschränkt.

Von den Büchern kommt die Bedeutung her, ja, aber browse und leafing through 
sind halt beide ein blättern, da sehe ich keinen Widerspruch zur möglichen 
Verwendung hier.

> "wühlen" wäre flapsig.  Etwas
> hochsprachlicher wäre noch "durchforsten", aber das trägt uns
> natürlich den Zorn der Förster für den Begriffsmißbrauch zu.
> "erkunden" wäre auch noch möglich.

Beim Erkunden fehlt mir die Bedeutung, dass man da einzelne Schritte einen 
nach dem anderen durchgehen kann. Das finde ich im Blättern weiterhin am 
besten wiederzuerkennen. Dann noch eher durchforsten als erkunden.

> >> > David Kastrup wrote:
> >> >>> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228
> >> >>> +msgid "Sign Off"
> >> >>> +msgstr "Freizeichnen"
> >> >>
> >> >> Gegenzeichnen?
> >> >
> >> > Abzeichnen!
> >>
> >> Absegnen.  Ich denke mal, in der Form mit "Ab" ist das dermaßen
> >> gebräuchlich, daß man damit keine religiösen Befindlichkeiten
> >> verletzt.
> >>
> >> Ansonsten: Abnicken oder Gutheißen.
> >
> > Absegnen ist zu flapsig, Abnicken und Gutheißen erst recht.
>
> Abnicken ja, aber Gutheißen ist nun wirklich ein hochsprachlicher
> Begriff.
>
> >  Abzeichnen wäre okay, aber das ist Freizeichnen auch.
>
> Freizeichnen ist viel zu nischensprachlich.  Mit Abzeichnen könnte ich
> leben, obwohl ich Gutheißen besser fände.

Abzeichnen ist ok.

Am Samstag, 21. Juli 2007 22:09 schrieb David Kastrup:
> After a view of the glossary:
>
> "amend" "ergänzen"
> ist nicht ganz korrekt.  "nachbessern" wäre da erheblich besser.

Ok.

> "message" würde ich als "Nachricht" statt "Meldung" übersetzen.

Irgendwie Geschmackssache. Man muss sich das ein bisschen im Kontext 
vorstellen: "Die Meldung zur Einspielung/Übertragung", "Die Nachricht zur 
Einspielung/Übertragung", ich würde da erstmal bei Meldung bleiben.

> "revert" "zurückkehren" würde ich eher als "revidieren" oder
> "aufheben" bezeichnen.

"revidieren" ist gut.

> "revision" ist wohl schlicht eine "Version" statt der "Revision", die
> einem das Finanzamt ins Haus bringt.

Auch das ist gut, allerdings frage ich mich natürlich auch, warum das Dingens 
dann nicht auch gleich auf Englisch "version" heißt :-)

Bisheriger Zwischenstand wird im glossary.csv nachgetragen; zur Anpassung von 
de.po hab ich noch keine Zeit gehabt, kommt aber sobald neue Strings drin 
sind.

Christian

Re: German translations

[Edgar Toernig]

> >> > +#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134
> >> > +msgid "Commit"
> >> > +msgstr "Übertragen"
> >>
> >> Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein
> >> passendes Substantiv zu finden.  "Sendung"?
> [...]
> Ich habe was: Einspielen, Ausspielen, Einspielung, Ausspielung.
> Symmetrisch, verständlich, als Verb und Substantiv zu gebrauchen.
>
> [usw]

Das ist genau der Grund, warum ich normalerweise keine deutschen
Lokalisierungen benutze - total unverstaendlicher Kauderwelsch.

Denkt doch bitte mal an die Zielgruppe!  Das sind Techniker, keine
Grossmuetter.  Ihr duerft Fachvokabular benutzen!  Und gerade hier
wird die Zielgruppe schon englische Dokumentation gelesen haben.
Solch zwanghaft eingedeutschten Begriffe verwirren da nur.
Also sagt doch bitte einfach "der Commit" und "comitten" wie es
jeder Techniker macht.  Ihr duerft auch "das Repository", "der
Index" und mMn auch ruhig "der Branch" benutzen.

Verstaendlichkeit, Klarheit, Exaktheit - das ist das oberste Ziel!
Wir sind doch keine Franzosen ;-)

Ciao, ET.


PS: bzgl. "Sign Off": "Gutheißen" ist zu lasch - das entspricht
    dem Ack'ed-by.

Re: German translations

[Christian Stimming]

Am Sonntag, 22. Juli 2007 16:52 schrieb Edgar Toernig:
> > >> > +msgid "Commit"
> > >> > +msgstr "Übertragen"
> > >>
> > >> Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein
> > >> passendes Substantiv zu finden.  "Sendung"?
> >
> > Ich habe was: Einspielen, Ausspielen, Einspielung, Ausspielung.
>
> Das ist genau der Grund, warum ich normalerweise keine deutschen
> Lokalisierungen benutze - total unverstaendlicher Kauderwelsch.
>
> Denkt doch bitte mal an die Zielgruppe!  

Ja, genau das sag ich doch.

> Das sind Techniker, keine 
> Grossmuetter.  Ihr duerft Fachvokabular benutzen!  Und gerade hier
> wird die Zielgruppe schon englische Dokumentation gelesen haben.

Nein. Die Zielgruppe der deutschen Übersetzung sind jene Techniker, die 
partout mit Englisch auf Kriegsfuß stehen. Jaja, solche gibt es. Und für 
solche muss man überlegen, ob es deutsche Begriffe gibt, die man in der 
gleichen Bedeutung verwenden kann. Das geht nicht so spontan - also bitte 
erstmal abwarten und selber überlegen. Die englischen Begriffe sind als 
fallback immer noch möglich, aber erstmal wird überlegt.

Ich bin auch für Anregungen dankbar, wie andere Übersetzer das denn gelöst 
haben. Das erwähnte TortoiseSVN mit einer IMHO gelungenen deutschen Doku hat 
commit=übertragen gewählt, ist aber bei checkout=auschecken geblieben. Die 
anderen SVN-Clients, bei denen man einen deutsche Übersetzung sehen kann, 
bieten da leider nur mindere Qualität und haben praktisch sämtliche 
Schlüsselworte auf Englisch gelassen.

> Solch zwanghaft eingedeutschten Begriffe verwirren da nur.
> Also sagt doch bitte einfach "der Commit" und "comitten" wie es
> jeder Techniker macht.  Ihr duerft auch "das Repository", "der
> Index" und mMn auch ruhig "der Branch" benutzen.

Nein. Wenn dir diese englischen Begriffe lieber sind, dann bleib gerne bei 
LANG=C bzw. en und fertig. Hier wird erstmal diskutiert, ob sich nicht doch 
deutsche Begriffe finden lassen. Es ist ja nicht so, als ob hier das 
allererste Mal ein SCM auf deutsch erklärt werden müsste.

> Verstaendlichkeit, Klarheit, Exaktheit - das ist das oberste Ziel!

- der deutschen Übersetzung, richtig! Wer das mit den englischen Begriffen 
erreichen will, bleibt bei LANG=C.

> PS: bzgl. "Sign Off": "Gutheißen" ist zu lasch - das entspricht
>     dem Ack'ed-by.

Ich finde da den Vorschlag "abzeichnen" bisher am besten.

Gruß

Christian

Re: German translations

[David Kastrup]

After a view of the glossary:

"amend" "ergänzen"

ist nicht ganz korrekt.  "nachbessern" wäre da erheblich besser.
"message" würde ich als "Nachricht" statt "Meldung" übersetzen.

"revert" "zurückkehren" würde ich eher als "revidieren" oder
"aufheben" bezeichnen.

"revision" ist wohl schlicht eine "Version" statt der "Revision", die
einem das Finanzamt ins Haus bringt.


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [PATCH 3/5] Internationalization of git-gui

[Shawn O. Pearce]

Christian Stimming <stimming@tuhh.de> wrote:
> Subject: [PATCH] Initial German translation for testing of i18n.
...
> diff --git a/po/de.po b/po/de.po
> new file mode 100644
> index 0000000..0592836
> --- /dev/null
> +++ b/po/de.po
> @@ -0,0 +1,265 @@
> +# Translation of git-gui to German.
> +# Copyright (C) 2007 Linux Torvalds

I didn't realize Linus wrote German.  ;-)

Or are you assigning the copyright to Linus, much as other chunks
of Git are copyrighted by Linus?

-- 
Shawn.

Re: [PATCH 3/5] Internationalization of git-gui

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Christian Stimming <stimming@tuhh.de> wrote:
>> Subject: [PATCH] Initial German translation for testing of i18n.
> ...
>> diff --git a/po/de.po b/po/de.po
>> new file mode 100644
>> index 0000000..0592836
>> --- /dev/null
>> +++ b/po/de.po
>> @@ -0,0 +1,265 @@
>> +# Translation of git-gui to German.
>> +# Copyright (C) 2007 Linux Torvalds
>
> I didn't realize Linus wrote German.  ;-)
>
> Or are you assigning the copyright to Linus, much as other chunks
> of Git are copyrighted by Linus?

The convention for xx.po, judging from the way template pot file
is written out, is to name the package's copyright holder, not
translation's, on that line.  So Linus does not have to have
anything to do with the German part, but I think the appropriate
name to place there is yours.

Re: [PATCH 3/5] Internationalization of git-gui

[Christian Stimming]

Am Sonntag, 22. Juli 2007 10:05 schrieb Junio C Hamano:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Christian Stimming <stimming@tuhh.de> wrote:
> >> Subject: [PATCH] Initial German translation for testing of i18n.
> >> diff --git a/po/de.po b/po/de.po
> >> new file mode 100644
> >> index 0000000..0592836
> >> --- /dev/null
> >> +++ b/po/de.po
> >> @@ -0,0 +1,265 @@
> >> +# Translation of git-gui to German.
> >> +# Copyright (C) 2007 Linux Torvalds
> >
> > I didn't realize Linus wrote German.  ;-)
> >
> > Or are you assigning the copyright to Linus, much as other chunks
> > of Git are copyrighted by Linus?
>
> The convention for xx.po, judging from the way template pot file
> is written out, is to name the package's copyright holder, not
> translation's, on that line.  

Exactly. That line should say that even though I have been the author of 
de.po, I still assign copyright (or the assign-able parts of it) to the 
package's copyright owner, which in this case is Linus. As Junio says, this 
is a suggestion from gettext, and I'd simply follow it here.

> So Linus does not have to have anything to do with the German part, 
> but I think the appropriate name to place there is yours.

s/yours/his/ ? Otherwise this sentence sounds like a contradiction to the 
previous one...

Christian

Re: [PATCH 3/5] Internationalization of git-gui

[Johannes Schindelin]

Hi,

On Sun, 22 Jul 2007, Christian Stimming wrote:

> Am Sonntag, 22. Juli 2007 10:05 schrieb Junio C Hamano:
> > "Shawn O. Pearce" <spearce@spearce.org> writes:
> > > Christian Stimming <stimming@tuhh.de> wrote:
> > >> Subject: [PATCH] Initial German translation for testing of i18n.
> > >> diff --git a/po/de.po b/po/de.po
> > >> new file mode 100644
> > >> index 0000000..0592836
> > >> --- /dev/null
> > >> +++ b/po/de.po
> > >> @@ -0,0 +1,265 @@
> > >> +# Translation of git-gui to German.
> > >> +# Copyright (C) 2007 Linux Torvalds
> > >
> > > I didn't realize Linus wrote German.  ;-)
> > >
> > > Or are you assigning the copyright to Linus, much as other chunks
> > > of Git are copyrighted by Linus?
> >
> > The convention for xx.po, judging from the way template pot file
> > is written out, is to name the package's copyright holder, not
> > translation's, on that line.  
> 
> Exactly. That line should say that even though I have been the author of 
> de.po, I still assign copyright (or the assign-able parts of it) to the 
> package's copyright owner, which in this case is Linus. As Junio says, 
> this is a suggestion from gettext, and I'd simply follow it here.

How about Junio instead?  Linus created Git, but Junio is the official 
maintainer (by mutual agreement).

Ciao,
Dscho

Re: [PATCH 3/5] Internationalization of git-gui

[Christian Stimming]

Am Sonntag, 22. Juli 2007 14:44 schrieb Johannes Schindelin:
> > > >> Subject: [PATCH] Initial German translation for testing of i18n.
> > > >> diff --git a/po/de.po b/po/de.po
> > > >> new file mode 100644
> > > >> index 0000000..0592836
> > > >> --- /dev/null
> > > >> +++ b/po/de.po
> > > >> @@ -0,0 +1,265 @@
> > > >> +# Translation of git-gui to German.
> > > >> +# Copyright (C) 2007 Linux Torvalds
> > > >
> > > > I didn't realize Linus wrote German.  ;-)
> > > >
> > > > Or are you assigning the copyright to Linus, much as other chunks
> > > > of Git are copyrighted by Linus?
> > >
> > > The convention for xx.po, judging from the way template pot file
> > > is written out, is to name the package's copyright holder, not
> > > translation's, on that line.
> >
> > Exactly. That line should say that even though I have been the author of
> > de.po, I still assign copyright (or the assign-able parts of it) to the
> > package's copyright owner, which in this case is Linus. As Junio says,
> > this is a suggestion from gettext, and I'd simply follow it here.
>
> How about Junio instead?  Linus created Git, but Junio is the official
> maintainer (by mutual agreement).

Then the copyright line should probably better read

Copyright (C) 2007 Shawn Pearce, et al.

because that's what the copyright for the other git-gui files say.

Christian

Re: [PATCH 3/5] Internationalization of git-gui

[Johannes Schindelin]

Hi,

On Sun, 22 Jul 2007, Christian Stimming wrote:

> Am Sonntag, 22. Juli 2007 14:44 schrieb Johannes Schindelin:
>
> > [Christian, I think, wrote]
> >
> > > That line should say that even though I have been the author of 
> > > de.po, I still assign copyright (or the assign-able parts of it) to 
> > > the package's copyright owner, which in this case is Linus. As Junio 
> > > says, this is a suggestion from gettext, and I'd simply follow it 
> > > here.
> >
> > How about Junio instead?  Linus created Git, but Junio is the official
> > maintainer (by mutual agreement).
> 
> Then the copyright line should probably better read
> 
> Copyright (C) 2007 Shawn Pearce, et al.
> 
> because that's what the copyright for the other git-gui files say.

Oops.  Yes, of course.

Ciao,
Dscho

Re: [PATCH 2/5] Internationalization of git-gui

[Shawn O. Pearce]

Christian Stimming <stimming@tuhh.de> wrote:
> Subject: [PATCH] Mark strings for translation.
> 
> The procedure [mc ...] will translate the strings through msgcat.
...
> Here I marked much more strings than in the previous patch, and as discussed
> the procedure [mc ...] is used for translation. Actually I think this pretty much 
> caught all occurrences of user-visible strings in *this* file; there will be many
> more strings in all the other files, of course.

Almost.  I noticed two that you did miss, and its because they are
totally weird.  We may want to rewrite this block of code first...

> @@ -1673,7 +1673,7 @@ if {[is_enabled transport]} {
>  menu .mbar.repository
>  
>  .mbar.repository add command \
> -	-label {Browse Current Branch's Files} \
> +	-label [mc "Browse Current Branch's Files"] \
>  	-command {browser::new $current_branch}
>  trace add variable current_branch write ".mbar.repository entryconf [.mbar.repository index last] -label \"Browse \$current_branch's Files\" ;#"
>  .mbar.repository add command \
> @@ -1682,69 +1682,69 @@ trace add variable current_branch write ".mbar.repository entryconf [.mbar.repos
>  .mbar.repository add separator
>  
>  .mbar.repository add command \
> -	-label {Visualize Current Branch's History} \
> +	-label [mc "Visualize Current Branch's History"] \
>  	-command {do_gitk $current_branch}
>  trace add variable current_branch write ".mbar.repository entryconf [.mbar.repository index last] -label \"Visualize \$current_branch's History\" ;#"
>  .mbar.repository add command \

See those two trace lines?  These things are setting up hooks to
change the menu item's label on the fly, so that the current branch
name is shown in the item label.  These will also need to use mc to
translate the string.  But they are in a double quoted string and will
be eval'd later by Tcl, so we actually need something like:

- trace add variable current_branch write ".mbar.repository entryconf [.mbar.repository index last] -label \"Visualize \$current_branch's History\" ;#"
+ trace add variable current_branch write ".mbar.repository entryconf [.mbar.repository index last] -label \[mc \"Visualize \$current_branch's History\"\] ;#"

These are (I think) the only two places in all of git-gui where
this wierdness happens.  Converting this trace pair to a normal
procedure may make it easier to manage for translation.

> -	.mbar.apple add command -label "About [appname]" \
> +	.mbar.apple add command -label [mc "About %s" appname] \

Bug. This needs to be:

+	.mbar.apple add command -label [mc "About %s" [appname]] \

You lost one level of [] there when you did the replacement.
I only noticed this during a fast scan through while deleting text.
I'll have to reread this patch more carefully later, before I apply
(or merge) it, to make sure we don't have more such cases.

-- 
Shawn.

Re: [PATCH 2/5] Internationalization of git-gui

[Christian Stimming]

Am Sonntag, 22. Juli 2007 09:45 schrieb Shawn O. Pearce:
> > Here I marked much more strings than in the previous patch, and as
> > discussed the procedure [mc ...] is used for translation. 
>
> Almost.  I noticed two that you did miss, and its because they are
> totally weird.  We may want to rewrite this block of code first...

Yes, I've noticed those two run-time strings as well; I simply deferred them 
to be dealt with at a later point in time. As you already say, they will have 
to be rewritten before they can be translated. Probably an extra layer of 
[format ...] will do.

> > @@ -1682,69 +1682,69 @@ trace add variable current_branch write
> > ".mbar.repository entryconf [.mbar.repos .mbar.repository add separator
> >
> >  .mbar.repository add command \
> > -	-label {Visualize Current Branch's History} \
> > +	-label [mc "Visualize Current Branch's History"] \
> >  	-command {do_gitk $current_branch}
> >  trace add variable current_branch write ".mbar.repository entryconf
> > [.mbar.repository index last] -label \"Visualize \$current_branch's
> > History\" ;#" .mbar.repository add command \
>
> But they are in a double quoted string and will
> be eval'd later by Tcl, so we actually need something like:
>
> - trace add variable current_branch write ".mbar.repository entryconf
> [.mbar.repository index last] -label \"Visualize \$current_branch's
> History\" ;#" + trace add variable current_branch write ".mbar.repository
> entryconf [.mbar.repository index last] -label \[mc \"Visualize
> \$current_branch's History\"\] ;#"

Err... I didn't get the latter one, but as I said, this can be deferred until 
later.

> > -	.mbar.apple add command -label "About [appname]" \
> > +	.mbar.apple add command -label [mc "About %s" appname] \
>
> Bug. This needs to be:
>
> +	.mbar.apple add command -label [mc "About %s" [appname]] \
>
> You lost one level of [] there when you did the replacement.

Oops, sorry, you are right. Also, I didn't test quite thoroughly after the 
s/_/mc/ replacement, compared to the original _ introduction, where I already 
caught this one once before.

> I only noticed this during a fast scan through while deleting text.
> I'll have to reread this patch more carefully later, before I apply
> (or merge) it, to make sure we don't have more such cases.

The appname thing was the only occurrence in this file, but it occurs several 
times.

Christian

Re: [PATCH 1/5] Internationalization of git-gui

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 6232 bytes --]

Hi,

On Sat, 21 Jul 2007, Christian Stimming wrote:

> This patch starts over from before the first i18n patch has been applied 
> and takes into account all discussion with Shawn. Currently I don't 
> quite know how to apply these patches to the "mob" branch because one 
> would have to first revert those patches from me that have been applied 
> there... Thanks.

Usually you solve this by forcing a non-fastforwarding push.  IOW you 
really revert part of the history.  You would not even have had to call 
"git revert" or "git reset", since you started from a defined commit, 
d36cd968378cd3e509434b1b9f43f1417fdba57e.

_However_: Junio already pushed into the 'mob' branch, and if you would 
have forced a non-fastforwarding push, this commit would have been lost.  
At least from the repo's POV.

So the only real option that makes sense is for you to register as a user 
at repo.or.cz, send me your user name, and for me to add you as user so 
that you can push into your own branch easily.

FWIW, this is what I did with your patch series:

- I looked at the first diff to find out which version of git-gui.sh it 
  was based on:

	diff --git a/git-gui.sh b/git-gui.sh
	index c5ff7c8..0c5ca46 100755
	--- a/git-gui.sh
	+++ b/git-gui.sh

  Ah, okay, git-gui.sh was at c5ff7c8.  What commit was that?  Ask "git 
  log --raw":

	...
	commit d36cd968378cd3e509434b1b9f43f1417fdba57e
	Author: Shawn O. Pearce <spearce@spearce.org>
	Date:   Thu Jul 19 00:43:16 2007 -0400

	    git-gui: Avoid unnecessary global statements when possible

	    [commit message]

	:100755 100755 0aabfba... c5ff7c8... M  git-gui.sh

  Good.  So it is based on d36cd968.  (If my decorate patch would be in 
  'master', I could have told you an easy name like "shawn/master~3" or 
  some such).

- I started a new branch:

  git checkout -b christian-new d36cd968

- Then I saved all your mails into an own mbox with my mail program.  I 
  had to edit that mbox a little, since you sent the complete headers in 
  the body, not in the mail header.  So I just stripped all the 
  mail headers and only left the ones from the mail bodies.

- After that I applied the patches with

  git am -i <mbox-file>

  I like the interactive mode, especially since Pine likes to add a dummy 
  mail at the beginning of the mbox file, which I do not want to commit, 
  of course ;-)

- There were no conflicts at all, and just to see that nothing untoward 
  happened, I compared the diffstats with "git log --stat shawn/master.."

  Come to think of it, it's even easier to check the object name of the 
  new git-gui.sh: "git ls-files --stage" says

	...
	100755 95dac55[...] 0       git-gui.sh

  Worked.  (I could also have said "git log --raw" to see that.)

- Just a quick "make && ./git-gui" test.  Ooops:

	$ LC_ALL=C make
	Generating catalog po/de.msg
	msgfmt --statistics --tcl po/de.po -l de -d po/
	po/de.po:32:9: invalid multibyte sequence
	po/de.po:36:18: invalid multibyte sequence
	po/de.po:48:32: invalid multibyte sequence
	...

  Looking into line 32 I see an ISO-8859-1 'ü'.  But in the header it says 
  that it's UTF-8.  Just a quick try: change that to ISO-8859-1, and 
  'make' says:

	$ LC_ALL=C make
	Generating catalog po/de.msg
	msgfmt --statistics --tcl po/de.po -l de -d po/
	62 translated messages.

  Much better.

  Okay, let's fix that up.  First stash the changes:

	$ git stash encoding fix

  Then find out which commit added po/de.msg:

	$ git log -1 po/de.po
	...
	    Initial German translation [...]

  Now on to editing the patch series:

	$ git rebase -i HEAD~5

  Mark "Initial German translation [...]" with the command "edit" instead 
  of "pick".  Save, and wait for half a second.

	...
	You can amend the commit now, with

	        git commit --amend

  Apply the stashed changes, and make sure that it's what I want:

	$ git stash apply
	...
	$ git diff
	...
	-"Content-Type: text/plain; charset=UTF-8\n"
	+"Content-Type: text/plain; charset=ISO-8859-1\n"
	...

  Yes!  Amend the commit, and for good measure, sign off on it (after 
  reading it, of course):

	$ git commit --amend -s po/de.po

  Mention that the encoding was changed by me, so if it is wrong, it is 
  all my fault, not yours.

  Now finish "rebasing"...

	$ git rebase --continue

  Make sure that it works now:

	$ make libdir=$(pwd)/lib && ./git-gui

  Yep.  Everything's fine.

  (Usually I go through this procedure in less than 3 minutes, but today I 
  took more than double that, since I wrote this email explaining my 
  actions...)

- Push to repo.or.cz (which is my 'origin' remote):

	$ git push origin HEAD:refs/heads/christian-new

- Now for the real fun: rebase it on top of Shawn's new master:

	# I have installed a remote 'shawn' pointing to git-gui.git
	$ git fetch shawn
	$ git rebase shawn/master
	...

  Worked.  Just like that.  Brilliant.

- Let's just cherry-pick Junio's change, which is the latest commit in 
  origin/mob:

	$ git cherry-pick origin/mob
	Auto-merged Makefile
	CONFLICT (content): Merge conflict in Makefile
	Automatic cherry-pick failed.  After resolving the conflicts,
	mark the corrected paths with 'git-add <paths>'
	and commit the result.
	When commiting, use the option '-c 2d29ab2' to retain authorship 
	and message.

  Conflict in Makefile.  Okay, no problem, edit it.  Ah, of course, Shawn 
  asked for automatic inferring of the available languages, while Junio 
  added "ja".  Just take the current version (the version between "<<<<" 
  and "====").

	$ git add -u
	$ git commit -c 2d29ab2

- Make the current revision my new 'master'.  That branch already exists, 
  and I am on 'christian-new', though.  No problem:

	$ git branch -M christian-new master

  (But if you do that with "-M", which means _force_ rename, make sure 
  twice that this is really what you want.)

- Push it.

	$ git push origin +master
	...
	refs/heads/master: da7b699[...] -> cc2b761b[...]

  The "+" is necessary, since I rebased it...

  If there were more pushers than just me, I'd verify that da7b699 is 
  indeed the old state of my master:

	$ git reflog
	...
	d36cd96... HEAD@{20}: checkout: moving from master to christian-new
	da7b699... HEAD@{21}: commit [...]

  Yep.

Good.  Happy.

Ciao,
Dscho

Re: [PATCH 1/5] Internationalization of git-gui

[Junio C Hamano]

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

> ...
> - Make the current revision my new 'master'.  That branch already exists, 
>   and I am on 'christian-new', though.  No problem:
>
> 	$ git branch -M christian-new master
>
>   (But if you do that with "-M", which means _force_ rename, make sure 
>   twice that this is really what you want.)
>
> - Push it.
>
> 	$ git push origin +master
> 	...
> 	refs/heads/master: da7b699[...] -> cc2b761b[...]
>
>   The "+" is necessary, since I rebased it...
>
>   If there were more pushers than just me, I'd verify that da7b699 is 
>   indeed the old state of my master:
>
> 	$ git reflog
> 	...
> 	d36cd96... HEAD@{20}: checkout: moving from master to christian-new
> 	da7b699... HEAD@{21}: commit [...]
>
>   Yep.
>
> Good.  Happy.

Two questions and a half.

 - The above means git-gui-i18n.git's master is rebased.  Is
   that the intention?  IOW, people are supposed to work on it
   with fetch+rebase, not fetch+merge (= pull)?

 - It seems that the tip of 'mob' now is out of sync wrt
   'master'.  What's the plan to update it with framework
   changes made in 'master' (e.g. addition of po/glossary.csv)?

While I think keeping a reference for consistent translation
(within one language's *.po file) is a useful practice,
the po/glossary.csv file on 'master' seems a way suboptimal
solution.  Currently it is:

        $ file po/glossary.csv
        po/glossary.csv: ISO-8859 text

        $ head -n 1 po/glossary.csv
        "English Term"  "de translation"

which implies that other languages will be added at the end
separated with <TAB>?

There are two HUGE problems with that.

 * Supporting many languages means looooong lines in that file.
   Translators for languages later on the line would have hard
   time updating or looking at that file.

 * Mixed encodings.  What if next language wants its strings in
   UTF-8?  How would you have that and ISO-8859 on a same line?

I would suggest having one glossary file per language.

Re: [PATCH 1/5] Internationalization of git-gui

[Christian Stimming]

Am Samstag, 21. Juli 2007 21:41 schrieb Junio C Hamano:
> While I think keeping a reference for consistent translation
> (within one language's *.po file) is a useful practice,
> the po/glossary.csv file on 'master' seems a way suboptimal
> solution.  Currently it is:
>
>         $ file po/glossary.csv
>         po/glossary.csv: ISO-8859 text

Oops. I created it with utf8 locally. Must have turned into latin1 either in 
my mailer or during Johannes' mbox tweaking.

(Also, the de.po was created in utf8 here and must have been messed up during 
transmission. Johannes, for future reference: All i18n files should probably 
be submitted as utf8, and if they have a different encoding, the submitter 
better gave a clear sign this was intentional.)

>         $ head -n 1 po/glossary.csv
>         "English Term"  "de translation"
>
> which implies that other languages will be added at the end
> separated with <TAB>?
>
> There are two HUGE problems with that.
>
>  * Supporting many languages means looooong lines in that file.
>    Translators for languages later on the line would have hard
>    time updating or looking at that file.
>
>  * Mixed encodings.  What if next language wants its strings in
>    UTF-8?  How would you have that and ISO-8859 on a same line?
>
> I would suggest having one glossary file per language.

Agreed. I propose to throw away the "add glossary" patch and I'll resubmit, 
this time in a separate po/glossary/ directory, where each language will get 
a po file for the glossary. 

As I've written in another thread: In the glossary for the gnucash project [1] 
we've actually added an extra 
directory and encourage translators to add an extra po file for their 
glossary translations. However, the glossary of gnucash has more than 150 
terms and many of them require to be defined clearly as well, as translators 
would otherwise be unable to translate them concisely. In git-gui, the 
glossary is 25 terms so far and I think the git documentation already 
contains enough definitions of all of them. Nevertheless, maybe it would make 
a better structure if the translations of the glossary are kept in a separate 
po file for each language. 

Christian

[1] 
http://svn.gnucash.org/trac/browser/gnucash/trunk/po/glossary/gnc-glossary.txt

Re: [PATCH 1/5] Internationalization of git-gui

[Johannes Schindelin]

Hi,

On Sat, 21 Jul 2007, Christian Stimming wrote:

> Am Samstag, 21. Juli 2007 21:41 schrieb Junio C Hamano:
> > While I think keeping a reference for consistent translation
> > (within one language's *.po file) is a useful practice,
> > the po/glossary.csv file on 'master' seems a way suboptimal
> > solution.  Currently it is:
> >
> >         $ file po/glossary.csv
> >         po/glossary.csv: ISO-8859 text
> 
> Oops. I created it with utf8 locally. Must have turned into latin1 either in 
> my mailer or during Johannes' mbox tweaking.

D'oh.  I think it was my tweaking.  But now, with 'mob' in place, there 
are less chances for me to fsck up.

Ciao,
Dscho

Re: [PATCH 1/5] Internationalization of git-gui

[Junio C Hamano]

Christian Stimming <stimming@tuhh.de> writes:

>> There are two HUGE problems with that.
>>
>>  * Supporting many languages means looooong lines in that file.
>>    Translators for languages later on the line would have hard
>>    time updating or looking at that file.
>>
>>  * Mixed encodings.  What if next language wants its strings in
>>    UTF-8?  How would you have that and ISO-8859 on a same line?
>>
>> I would suggest having one glossary file per language.
>
> Agreed. I propose to throw away the "add glossary" patch and I'll resubmit, 
> this time in a separate po/glossary/ directory, where each language will get 
> a po file for the glossary. 
>
> As I've written in another thread: In the glossary for the gnucash project [1] 
> we've actually added an extra 
> directory and encourage translators to add an extra po file for their 
> glossary translations. However, the glossary of gnucash has more than 150 
> terms and many of them require to be defined clearly as well, as translators 
> would otherwise be unable to translate them concisely. In git-gui, the 
> glossary is 25 terms so far and I think the git documentation already 
> contains enough definitions of all of them. Nevertheless, maybe it would make 
> a better structure if the translations of the glossary are kept in a separate 
> po file for each language. 

Actually, I would even suggest that we should NOT have a
separate glossary file at all, if gettext suite allows what I
outline below.

How about having it as a part of header comment in each of the
xx.po file?

The division of labor I think would make sense for message l10n
process goes like this:

 - The software developer (primarily Shawn): responsible for
   marking messages subject to i18n;

 - The i18n coordinator (could be Shawn but anybody else can
   volunteer; as things stand, I think Christian and Johannes
   are doing this): responsible for running "make
   po/git-gui.pot; make update-po" from time to time in order to
   keep po/*.po in sync with the vocabulary.

   initially, populate "glossary" part in po/git-gui.pot;

   as needed, add entries "glossary" part in po/git-gui.pot, and
   (if possible) add corresponding placeholders to po/*.po;

 - Translators (one for each language): responsible for updating
   po/xx.po file;

   initially, start by copying po/git-gui.pot to create
   po/xx.po;

   maintainance of "glossary" part of po/xx.po could also be
   made this person's responsibility instead of i18n
   coordinator's.

This way, the translators do not have to be so familiar with the
gettext toolchain nor even have to have gettext installed.

     

Re: [PATCH 1/5] Internationalization of git-gui

[Johannes Schindelin]

Hi,

On Sat, 21 Jul 2007, Junio C Hamano wrote:

> The division of labor I think would make sense for message l10n
> process goes like this:
> 
>  - The software developer (primarily Shawn): responsible for
>    marking messages subject to i18n;
> 
>  - The i18n coordinator (could be Shawn but anybody else can
>    volunteer; as things stand, I think Christian and Johannes
>    are doing this): responsible for running "make
>    po/git-gui.pot; make update-po" from time to time in order to
>    keep po/*.po in sync with the vocabulary.
> 
>    initially, populate "glossary" part in po/git-gui.pot;
> 
>    as needed, add entries "glossary" part in po/git-gui.pot, and
>    (if possible) add corresponding placeholders to po/*.po;
> 
>  - Translators (one for each language): responsible for updating
>    po/xx.po file;
> 
>    initially, start by copying po/git-gui.pot to create
>    po/xx.po;
> 
>    maintainance of "glossary" part of po/xx.po could also be
>    made this person's responsibility instead of i18n
>    coordinator's.
> 
> This way, the translators do not have to be so familiar with the
> gettext toolchain nor even have to have gettext installed.

Makes tons of sense to me.

Ciao,
Dscho

Re: [PATCH 1/5] Internationalization of git-gui

[Christian Stimming]

Am Samstag, 21. Juli 2007 23:28 schrieb Junio C Hamano:
> > Agreed. I propose to throw away the "add glossary" patch and I'll
> > resubmit, this time in a separate po/glossary/ directory, where each
> > language will get a po file for the glossary.
>
> Actually, I would even suggest that we should NOT have a
> separate glossary file at all, if gettext suite allows what I
> outline below.
>
> How about having it as a part of header comment in each of the
> xx.po file?

I don't think this would work well. In particular, you don't get all the nice 
gettext *merging* features that you only get with a full-blown po file.

> The division of labor I think would make sense for message l10n
> process goes like this:
>
>  - The software developer (primarily Shawn): responsible for
>    marking messages subject to i18n;

Yes, except those developers who don't happen to be translators as well tend 
to forget the markups. I don't blame anyone for doing so - just keep in mind 
that translators have to give feedback about missing markups, and they 
hopefully will do so.

>  - The i18n coordinator (could be Shawn but anybody else can
>    volunteer; as things stand, I think Christian and Johannes
>    are doing this): responsible for running "make
>    po/git-gui.pot; make update-po" from time to time in order to
>    keep po/*.po in sync with the vocabulary.

Actually, please DO NOT RUN update-po except right before a new tarball is 
being packaged and distributed! It sucks royally if I have updated my de.po 
translation, only to discover someone has run update-po on the server and I 
have to figure out how to get out of the de.po conflicts. There will be 
conflicts after each and every update-po because the line numbers in the po 
file will have changed inevitably -- but the actualy content in terms of 
messages might be completely unchanged.

For that reason, please use the update-po rule AS SELDOM AS POSSIBLE. Thanks a 
lot.

>    initially, populate "glossary" part in po/git-gui.pot;
>
>    as needed, add entries "glossary" part in po/git-gui.pot, and
>    (if possible) add corresponding placeholders to po/*.po;

Again, this doesn't work well, and depending on the po file editor that is 
used by a translator they might not see this comment block anyway. I would 
instead propose a subdirectory po/glossary; a CSV file that contains the 
terms itself; a csv-to-po converter script that will turn the terms into a 
git-gui-glossary.pot; and a po file for each language.

>  - Translators (one for each language): responsible for updating
>    po/xx.po file;
>
>    initially, start by copying po/git-gui.pot to create
>    po/xx.po;
>
>    maintainance of "glossary" part of po/xx.po could also be
>    made this person's responsibility instead of i18n
>    coordinator's.
>
> This way, the translators do not have to be so familiar with the
> gettext toolchain nor even have to have gettext installed.

Translators who are unfamiliar with gettext are a mixed blessing. Anyone is 
able to contribute a bunch of initial string translations, especially if 
there hasn't been a translation before. But if someone or a team wants to 
achieve a really *high-quality*, 100%, consistent, and understandable 
translation, the translators must be able to test the translation a lot, 
which implies they must be able to generate the .msg files, which requires 
the gettext toolchain anyway. For that reason I wouldn't spent too much 
effort to enable translation work without gettext tools; instead, I'd rather 
encourage to optimize the setup for those translators that have the full 
toolchain available.

Christian

Re: [PATCH 1/5] Internationalization of git-gui

[Johannes Schindelin]

Hi,

On Sun, 22 Jul 2007, Christian Stimming wrote:

> Am Samstag, 21. Juli 2007 23:28 schrieb Junio C Hamano:
>
> >  - The i18n coordinator (could be Shawn but anybody else can
> >    volunteer; as things stand, I think Christian and Johannes
> >    are doing this): responsible for running "make
> >    po/git-gui.pot; make update-po" from time to time in order to
> >    keep po/*.po in sync with the vocabulary.
> 
> Actually, please DO NOT RUN update-po except right before a new tarball 
> is being packaged and distributed! It sucks royally if I have updated my 
> de.po translation, only to discover someone has run update-po on the 
> server and I have to figure out how to get out of the de.po conflicts.

I plan to work on that.  It seems to be pretty easy to define a sane merge 
behaviour, and we have gitattributes: by setting "*.po diff=po merge=po" 
we can provide a custom merge program, just for .po files.

> >  - Translators (one for each language): responsible for updating
> >    po/xx.po file;
> >
> >    initially, start by copying po/git-gui.pot to create
> >    po/xx.po;
> >
> >    maintainance of "glossary" part of po/xx.po could also be
> >    made this person's responsibility instead of i18n
> >    coordinator's.
> >
> > This way, the translators do not have to be so familiar with the
> > gettext toolchain nor even have to have gettext installed.
> 
> Translators who are unfamiliar with gettext are a mixed blessing. [...] 
> I wouldn't spent too much effort to enable translation work without 
> gettext tools; instead, I'd rather encourage to optimize the setup for 
> those translators that have the full toolchain available.

You need not work on the "without gettext toolchain" part; I will.  Let's 
see how far I get ;-)

Ciao,
Dscho

[PATCH] Add glossary that can be converted into a po file for each language.

[Christian Stimming]

Signed-off-by: Christian Stimming <stimming@tuhh.de>
---

Am Samstag, 21. Juli 2007 23:28 schrieb Junio C Hamano:
> >> I would suggest having one glossary file per language.
> >
> > Agreed. I propose to throw away the "add glossary" patch and I'll
> > resubmit, this time in a separate po/glossary/ directory, where each
> > language will get a po file for the glossary.
>
> Actually, I would even suggest that we should NOT have a
> separate glossary file at all, if gettext suite allows what I
> outline below.
>
> How about having it as a part of header comment in each of the
> xx.po file?

As I already wrote: Having a glossary in the header of the po file has 
some (IMHO serious) drawbacks. For that reason I've pushed this patch
to the mob branch: It contains one tab-separated text file with the relevant
terms *plus their definition* (for now, pulled from 
git/Documentation/glossary.txt). As an example, you also see the German
glossary translation - and having the definition available there as well (and 
having it updated by running make update-po) is indeed a huge advantage.

 po/glossary/Makefile             |    9 ++
 po/glossary/de.po                |  151 ++++++++++++++++++++++++++++++++++++++
 po/glossary/git-gui-glossary.txt |   34 +++++++++
 po/glossary/txt-to-pot.sh        |   48 ++++++++++++
 4 files changed, 242 insertions(+), 0 deletions(-)
 create mode 100644 po/glossary/Makefile
 create mode 100644 po/glossary/de.po
 create mode 100644 po/glossary/git-gui-glossary.txt
 create mode 100755 po/glossary/txt-to-pot.sh

diff --git a/po/glossary/Makefile b/po/glossary/Makefile
new file mode 100644
index 0000000..749aa2e
--- /dev/null
+++ b/po/glossary/Makefile
@@ -0,0 +1,9 @@
+PO_TEMPLATE = git-gui-glossary.pot
+
+ALL_POFILES = $(wildcard *.po)
+
+$(PO_TEMPLATE): $(subst .pot,.txt,$(PO_TEMPLATE))
+	./txt-to-pot.sh $< > $@
+
+update-po:: git-gui-glossary.pot
+	$(foreach p, $(ALL_POFILES), echo Updating $p ; msgmerge -U $p $(PO_TEMPLATE) ; )
diff --git a/po/glossary/de.po b/po/glossary/de.po
new file mode 100644
index 0000000..0d07f68
--- /dev/null
+++ b/po/glossary/de.po
@@ -0,0 +1,151 @@
+# Translation of git-gui glossary to German
+# Copyright (C) 2007 Shawn Pearce, et al.
+# This file is distributed under the same license as the git package.
+# Christian Stimming <stimming@tuhh.de>, 2007
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: git-gui glossary\n"
+"PO-Revision-Date: 2007-07-23 22:07+0200\n"
+"Last-Translator: Christian Stimming <stimming@tuhh.de>\n"
+"Language-Team: German \n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#. "English Definition (Dear translator: This file will never be visible to the user! It should only serve as a tool for you, the translator. Nothing more.)"
+msgid ""
+"English Term (Dear translator: This file will never be visible to the user!)"
+msgstr "Deutsche Übersetzung"
+
+#. ""
+msgid "amend"
+msgstr "nachbessern (ergänzen)"
+
+#. ""
+msgid "annotate"
+msgstr "annotieren"
+
+#. "A 'branch' is an active line of development."
+msgid "branch [noun]"
+msgstr "Zweig"
+
+#. ""
+msgid "branch [verb]"
+msgstr "verzweigen"
+
+#. ""
+msgid "checkout [noun]"
+msgstr "Auscheck? Ausspielung? Abruf?"
+
+#. "The action of updating the working tree to a revision which was stored in the object database."
+msgid "checkout [verb]"
+msgstr "auschecken? ausspielen? abrufen?"
+
+#. "A single point in the git history."
+msgid "commit [noun]"
+msgstr "Übertragung (Sendung?, Übergabe?, Einspielung?, Ablagevorgang?)"
+
+#. "The action of storing a new snapshot of the project's state in the git history."
+msgid "commit [verb]"
+msgstr "übertragen (senden?, übergeben?, einspielen?, einpflegen?, ablegen?)"
+
+#. ""
+msgid "diff [noun]"
+msgstr "Vergleich"
+
+#. ""
+msgid "diff [verb]"
+msgstr "vergleichen"
+
+#. "A fast-forward is a special typ of merge where you have a revision and you are merging another branch's changes that happen to be a descendant of what you have."
+msgid "fast forward merge"
+msgstr "Schnellzusammenführung"
+
+#. "Fetching a branch means to get the branch's head from a remote repository, to find out which objects are missing from the local object database, and to get them, too."
+msgid "fetch"
+msgstr "anfordern (holen?)"
+
+#. "A collection of files. The index is a stored version of your working tree."
+msgid "index (in git-gui: staging area)"
+msgstr "Bereitstellung"
+
+#. "A successful merge results in the creation of a new commit representing the result of the merge."
+msgid "merge [noun]"
+msgstr "Zusammenführung"
+
+#. "To bring the contents of another branch into the current branch."
+msgid "merge [verb]"
+msgstr "zusammenführen"
+
+#. ""
+msgid "message"
+msgstr "Meldung (Nachricht?)"
+
+#. "Pulling a branch means to fetch it and merge it."
+msgid "pull"
+msgstr "übernehmen (ziehen?)"
+
+#. "Pushing a branch means to get the branch's head ref from a remote repository, and ... (well, can someone please explain it for mere mortals?)"
+msgid "push"
+msgstr "ausliefern (hochladen? verschicken? schieben?)"
+
+#. ""
+msgid "redo"
+msgstr "wiederholen"
+
+#. "A collection of refs (?) together with an object database containing all objects which are reachable from the refs... (oops, you've lost me here. Again, please an explanation for mere mortals?)"
+msgid "repository"
+msgstr "Projektarchiv"
+
+#. ""
+msgid "reset"
+msgstr "zurücksetzen"
+
+#. ""
+msgid "revert"
+msgstr "revidieren (aufheben?, zurückkehren?)"
+
+#. "A particular state of files and directories which was stored in the object database."
+msgid "revision"
+msgstr "Version? Revision?"
+
+#. ""
+msgid "sign off"
+msgstr "abzeichnen (gegenzeichnen?, freizeichnen?, absegnen?)"
+
+#. ""
+msgid "staging area"
+msgstr "Bereitstellung"
+
+#. ""
+msgid "status"
+msgstr "Status"
+
+#. "A ref pointing to a tag or commit object"
+msgid "tag [noun]"
+msgstr "Markierung"
+
+#. ""
+msgid "tag [verb]"
+msgstr "markieren"
+
+#. "A regular git branch that is used to follow changes from another repository."
+msgid "tracking branch"
+msgstr "? Entfernter Zweig? Folgezweig?"
+
+#. ""
+msgid "undo"
+msgstr "rückgängig"
+
+#. ""
+msgid "update"
+msgstr "aktualisieren"
+
+#. ""
+msgid "verify"
+msgstr "überprüfen"
+
+#. "The tree of actual checked out files."
+msgid "working copy, working tree"
+msgstr "Arbeitskopie"
diff --git a/po/glossary/git-gui-glossary.txt b/po/glossary/git-gui-glossary.txt
new file mode 100644
index 0000000..e079bb2
--- /dev/null
+++ b/po/glossary/git-gui-glossary.txt
@@ -0,0 +1,34 @@
+"English Term (Dear translator: This file will never be visible to the user!)"	"English Definition (Dear translator: This file will never be visible to the user! It should only serve as a tool for you, the translator. Nothing more.)"
+"amend"	""
+"annotate"	""
+"branch [noun]"	"A 'branch' is an active line of development."
+"branch [verb]"	""
+"checkout [noun]"	""
+"checkout [verb]"	"The action of updating the working tree to a revision which was stored in the object database."
+"commit [noun]"	"A single point in the git history."
+"commit [verb]"	"The action of storing a new snapshot of the project's state in the git history."
+"diff [noun]"	""
+"diff [verb]"	""
+"fast forward merge"	"A fast-forward is a special typ of merge where you have a revision and you are merging another branch's changes that happen to be a descendant of what you have."
+"fetch"	"Fetching a branch means to get the branch's head from a remote repository, to find out which objects are missing from the local object database, and to get them, too."
+"index (in git-gui: staging area)"	"A collection of files. The index is a stored version of your working tree."
+"merge [noun]"	"A successful merge results in the creation of a new commit representing the result of the merge."
+"merge [verb]"	"To bring the contents of another branch into the current branch."
+"message"	""
+"pull"	"Pulling a branch means to fetch it and merge it."
+"push"	"Pushing a branch means to get the branch's head ref from a remote repository, and ... (well, can someone please explain it for mere mortals?)"
+"redo"	""
+"repository"	"A collection of refs (?) together with an object database containing all objects which are reachable from the refs... (oops, you've lost me here. Again, please an explanation for mere mortals?)"
+"reset"	""
+"revert"	""
+"revision"	"A particular state of files and directories which was stored in the object database."
+"sign off"	""
+"staging area"	""
+"status"	""
+"tag [noun]"	"A ref pointing to a tag or commit object"
+"tag [verb]"	""
+"tracking branch"	"A regular git branch that is used to follow changes from another repository."
+"undo"	""
+"update"	""
+"verify"	""
+"working copy, working tree"	"The tree of actual checked out files."
diff --git a/po/glossary/txt-to-pot.sh b/po/glossary/txt-to-pot.sh
new file mode 100755
index 0000000..8a8f976
--- /dev/null
+++ b/po/glossary/txt-to-pot.sh
@@ -0,0 +1,48 @@
+#!/bin/sh
+# This is a very, _very_, simple script to convert a tab-separated
+# .txt file into a .pot/.po.
+# Its not clever but it took me 2 minutes to write :)
+# Michael Twomey <michael.twomey@ireland.sun.com>
+# 23 March 2001
+# with slight GnuCash modifications by Christian Stimming <stimming@tuhh.de> 
+# 19 Aug 2001, 23 Jul 2007
+
+#check args
+if [ $# -eq 0 ]
+then
+	cat <<!
+Usage: `basename $0` git-gui-glossary.txt > git-gui-glossary.pot
+!
+	exit 1;
+fi
+
+GLOSSARY_CSV="$1";
+
+if [ ! -f "$GLOSSARY_CSV" ]
+then
+	echo "Can't find $GLOSSARY_CSV.";
+	exit 1;
+fi
+
+cat <<!
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: `date +'%Y-%m-%d %H:%M%z'`\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=CHARSET\n"
+"Content-Transfer-Encoding: ENCODING\n"
+
+!
+
+#Yes this is the most simple awk script you've ever seen :)
+awk -F'\t' '{if ($2 != "") print "#. "$2; print "msgid "$1; print "msgstr \"\"\n"}' \
+$GLOSSARY_CSV
-- 
1.5.2

Re: [PATCH] Add glossary that can be converted into a po file for each language.

[Junio C Hamano]

Christian Stimming <stimming@tuhh.de> writes:

> As I already wrote: Having a glossary in the header of the po file has 
> some (IMHO serious) drawbacks.

Yeah, that was me talking without knowing what are the usual
workflows with gettext toolchain.  A separate glossary that
properly is PO is much nicer.  We could even use that in the
help text.

Re: [PATCH] Add glossary that can be converted into a po file for each language.

[Junio C Hamano]

Christian Stimming <stimming@tuhh.de> writes:

> diff --git a/po/glossary/git-gui-glossary.txt b/po/glossary/git-gui-glossary.txt
> new file mode 100644
> index 0000000..e079bb2
> --- /dev/null
> +++ b/po/glossary/git-gui-glossary.txt
> @@ -0,0 +1,34 @@
> +"English Term (Dear translator: This file will never be visible to the user!)"	"English Definition (Dear translator: This file will never be visible to the user! It should only serve as a tool for you, the translator. Nothing more.)"
> +"amend"	""
> +"annotate"	""
> +"branch [noun]"	"A 'branch' is an active line of development."
> +"branch [verb]"	""
> +"checkout [noun]"	""
> +"checkout [verb]"	"The action of updating the working tree to a revision which was stored in the object database."
> +"commit [noun]"	"A single point in the git history."

I wonder.... couldn't this be written as a Tcl array that maps
word to its definition, marked with [mc] 'gettext'ese, perhaps,
glossary.tcl?  Then perhaps git-gui can include it and have a
user-visible glossary as part of its help system.

Am I dreaming, or too drunk?

Re: [PATCH] Add glossary that can be converted into a po file for each language.

[Christian Stimming]

Quoting Junio C Hamano <gitster@pobox.com>:
>> +++ b/po/glossary/git-gui-glossary.txt
>> @@ -0,0 +1,34 @@
>> +"English Term (Dear translator: This file will never be visible to  
>>  the user!)"	"English Definition (Dear translator: This file will   
>> never be visible to the user! It should only serve as a tool for   
>> you, the translator. Nothing more.)"
>> +"amend"	""
>> +"annotate"	""
>> +"branch [noun]"	"A 'branch' is an active line of development."
>> +"branch [verb]"	""
>> +"checkout [noun]"	""
>> +"checkout [verb]"	"The action of updating the working tree to a   
>> revision which was stored in the object database."
>> +"commit [noun]"	"A single point in the git history."
>
> I wonder.... couldn't this be written as a Tcl array that maps
> word to its definition, marked with [mc] 'gettext'ese, perhaps,
> glossary.tcl?  Then perhaps git-gui can include it and have a
> user-visible glossary as part of its help system.

I'm not so sure about this idea. I'd expect the glossary definitions  
for the translators to emphasize other issues than what a user-visible  
glossary would explain. For the user, the glossary should explain what  
each term means and what the user can *do* with this. For the  
translator, the glossary should explain what each term means and where  
it appears in the project (and which other terms it should be  
distinguished from). Also, the translator glossary IMHO should collect  
warnings about potential ambiguities as well (including the very clear  
distinction between noun and verb). Whereas the user glossary is  
probably much more verbose in what it explains, but doesn't emphasize  
as much the clear differences between verb and noun and so on.

> Am I dreaming, or too drunk?

You tell me :-)

Christian

Re: [PATCH 1/5] Internationalization of git-gui

[Johannes Schindelin]

Hi,

On Sat, 21 Jul 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > ...
> > - Make the current revision my new 'master'.  That branch already exists, 
> >   and I am on 'christian-new', though.  No problem:
> >
> > 	$ git branch -M christian-new master
> >
> >   (But if you do that with "-M", which means _force_ rename, make sure 
> >   twice that this is really what you want.)
> >
> > - Push it.
> >
> > 	$ git push origin +master
> > 	...
> > 	refs/heads/master: da7b699[...] -> cc2b761b[...]
> >
> >   The "+" is necessary, since I rebased it...
> >
> >   If there were more pushers than just me, I'd verify that da7b699 is 
> >   indeed the old state of my master:
> >
> > 	$ git reflog
> > 	...
> > 	d36cd96... HEAD@{20}: checkout: moving from master to christian-new
> > 	da7b699... HEAD@{21}: commit [...]
> >
> >   Yep.
> >
> > Good.  Happy.
> 
> Two questions and a half.
> 
>  - The above means git-gui-i18n.git's master is rebased.  Is
>    that the intention?  IOW, people are supposed to work on it
>    with fetch+rebase, not fetch+merge (= pull)?

Okay, you have me there.  Usually I am the one saying "rebasing is bad".  
So I'll refrain from that practice.  From now on, 'master' will _not_ be 
rebased.  From time to time I will prepare 'for-shawn' branches, which are 
"master rebased onto git-gui".

In related news, I will push to 'mob' whenever I update 'master'.  I will 
never force a push to 'mob', and neither should anybody else have to.  
(Except in the case that you want to correct one of your pushes.)

>  - It seems that the tip of 'mob' now is out of sync wrt
>    'master'.  What's the plan to update it with framework
>    changes made in 'master' (e.g. addition of po/glossary.csv)?

IMHO the best practice is to keep it up-to-date with 'master', as I 
outlined above.

> [Half a question about po/glossary.csv]

This was answered by Christian, I guess.

Ciao,
Dscho

Re: [PATCH 1/5] Internationalization of git-gui

[Junio C Hamano]

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

>> Two questions and a half.
>> 
>>  - The above means git-gui-i18n.git's master is rebased.  Is
>>    that the intention?  IOW, people are supposed to work on it
>>    with fetch+rebase, not fetch+merge (= pull)?
>
> Okay, you have me there.  Usually I am the one saying "rebasing is bad".  
> So I'll refrain from that practice.  From now on, 'master' will _not_ be 
> rebased.  From time to time I will prepare 'for-shawn' branches, which are 
> "master rebased onto git-gui".

I did not mean to say "rebase is bad".  Quite the contrary.

Rebase is bad for a repository meant for public consumption of
the under-development-snapshot, like git.git's 'master' and
'next'.  For a repository like git-gui-i18n whose sole point is
to serve as a public gathering point of narrowly focused area of
development (only translation of messages), I actually think
"everybody fetches and rebases" workflow is perfectly fine, as
long as all participants understand what the expected workflows
are.  My comment was more about making it clear what the policy
is to its intended audience.

Rebasing git-gui-i18n to keep its history clean would eventually
allow you to merge it directly into git-gui.  But if you are not
aiming for that (and you said your plan is to cherry pick the
result, not to merge, which is fine), then rebasing would no buy
you anything, so I think it would be a reasonable and manageable
workflow to:

 - people fork from 'mob', push back to 'mob';

 - you 
   - build 'master' by cherry picking good bits from 'mob', and
   - do your own fixups and framework changes on 'master',
   - merge 'master' back to 'mob' to allow contributors to
     adjust their work on the updated 'master' by simply
     following 'mob',

 - and eventually clean-up 'master' to make it mergeable and/or
   applicable to git-gui itself.

Re: [PATCH 1/5] Internationalization of git-gui

[Johannes Schindelin]

Hi,

On Sat, 21 Jul 2007, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> Two questions and a half.
> >> 
> >>  - The above means git-gui-i18n.git's master is rebased.  Is
> >>    that the intention?  IOW, people are supposed to work on it
> >>    with fetch+rebase, not fetch+merge (= pull)?
> >
> > Okay, you have me there.  Usually I am the one saying "rebasing is bad".  
> > So I'll refrain from that practice.  From now on, 'master' will _not_ be 
> > rebased.  From time to time I will prepare 'for-shawn' branches, which are 
> > "master rebased onto git-gui".
> 
> I did not mean to say "rebase is bad".  Quite the contrary.

Yeah, I was not really precise.  Rebase is only bad for branches that want 
to be tracked.

As you can see from my work on rebase -i, I recently converted to an avid 
user of rebase, from somebody who detested the feature a year ago.

> [...] I think it would be a reasonable and manageable workflow to:
> 
>  - people fork from 'mob', push back to 'mob';
> 
>  - you 
>    - build 'master' by cherry picking good bits from 'mob', and
>    - do your own fixups and framework changes on 'master',
>    - merge 'master' back to 'mob' to allow contributors to
>      adjust their work on the updated 'master' by simply
>      following 'mob',
> 
>  - and eventually clean-up 'master' to make it mergeable and/or
>    applicable to git-gui itself.

I plan to pull and push from mob, from time to time 
cherry-picking/rebasing and cleaning up to a branch called 'for-shawn'.  
To keep things a little synchronised, I plan to make grafts at stages 
where master^{tree} = for-shawn^{tree}, so that rebase is easier.

Ciao,
Dscho

Re: [PATCH 1/5] Internationalization of git-gui

[Shawn O. Pearce]

Christian Stimming <stimming@tuhh.de> wrote:
> Subject: [PATCH] Initialize msgcat (gettext).
...
> diff --git a/git-gui.sh b/git-gui.sh
> index c5ff7c8..0c5ca46 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> @@ -108,6 +108,12 @@ if {$idx ne {}} {
>  }
>  unset -nocomplain oguirel idx fd
>  
> +## Internationalization (i18n) through msgcat and gettext. See
> +## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html
> +package require msgcat
> +::msgcat::mcload [file join $oguilib msgs]
> +namespace import ::msgcat::mc
> +

Thanks.  We'll probably also want to modify the lib/class.tcl to
import ::msgcat::mc into the class namespace when it creates it.
I use that class thing throught most of git-gui, especially for
UI code.  About 50% of git-gui has been converted to use class,
the other 50% is just global and is still in git-gui.sh.  ;-)

-- 
Shawn.

Re: [PATCH 1/5] Internationalization of git-gui

[Christian Stimming]

Am Sonntag, 22. Juli 2007 09:38 schrieb Shawn O. Pearce:
> > +## Internationalization (i18n) through msgcat and gettext. See
> > +## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html
> > +package require msgcat
> > +::msgcat::mcload [file join $oguilib msgs]
> > +namespace import ::msgcat::mc
>
> Thanks.  We'll probably also want to modify the lib/class.tcl to
> import ::msgcat::mc into the class namespace when it creates it.
> I use that class thing throught most of git-gui, especially for
> UI code.  About 50% of git-gui has been converted to use class,
> the other 50% is just global and is still in git-gui.sh.  ;-)

As I was adding the markup in all the other files, I didn't have to add 
another import statement anywhere else. Seems like the global mc procedure 
works just fine.

In other words, if you think the mc procedure should be imported in another 
place as well, please do so because I don't know your future plans with class 
structure (and I also don't need to know for adding the i18n support right 
now).

Thanks,

Christian

Re: [PATCH 1/5] Internationalization of git-gui

[Shawn O. Pearce]

Christian Stimming <stimming@tuhh.de> wrote:
> Am Sonntag, 22. Juli 2007 09:38 schrieb Shawn O. Pearce:
> > > +## Internationalization (i18n) through msgcat and gettext. See
> > > +## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html
> > > +package require msgcat
> > > +::msgcat::mcload [file join $oguilib msgs]
> > > +namespace import ::msgcat::mc
> >
> > Thanks.  We'll probably also want to modify the lib/class.tcl to
> > import ::msgcat::mc ...
> 
> As I was adding the markup in all the other files, I didn't have to add 
> another import statement anywhere else. Seems like the global mc procedure 
> works just fine.
> 
> In other words, if you think the mc procedure should be imported in another 
> place as well, please do so because I don't know your future plans with class 
> structure (and I also don't need to know for adding the i18n support right 
> now).

Hmm.  Actually that makes sense.  We probably don't need to make
any changes, other than to make sure we don't override the "mc"
definition in any of the other UI namespaces, since it is currently
being inherited from :: (the global namespace).

Thanks.

-- 
Shawn.

Re: [PATCH] Internationalization of git-gui

[Christian Stimming]

Quoting Brett Schwarz <brett_schwarz@yahoo.com>:
> Also, if the message catalogs are in a common location, then it   
> might be worth looking into having gitk utilize these msg catalogs   
> as well.

You mean you suggest to re-use existing msg catalogs in addition to  
ones that are created on our own? Well, from the i18n coordination  
work in another project (gnucash) I wouldn't expect any noticable  
benefit from doing so. The re-usable parts of translations are rather  
limited, basically limited to the standard menu entries and some more  
single-word strings (Yes/No/Cancel...). But even then re-using other  
translations might already decrease the quality of your own  
translation, because other translators of packages might already have  
chosen a different translation for e.g. "Cancel". For that reason I  
strongly suggest using one single msg catalog for one single project,  
so that the translator is even able to make sure each word is  
translated into the same translation throughout the project.

(I also strongly suggest creating and translating a glossary of the  
important terms before starting to translate the msg catalog itself,  
but that's a different issue.)

> p.s. the frink tool (http://wiki.tcl.tk/2611) is supposed to be able  
>  to convert -text and -label switches to use msgcat...it might be   
> worth looking into, instead of manually editing git-gui/gitk

Thanks for the pointer. However, the -text and -label switches can be  
found and edited rather easily by keyboard macros and such. More  
important than this are some changes that are necessary in order to  
obtain strings that are actually translatable, such as

-	.mbar.apple add command -label "About [appname]" \
+	.mbar.apple add command -label [format [_ "About %s"] [appname]] \

and you will agree those can only be done manually anyway.

Christian