Re: [PATCH] Internationalization of git-gui

Christian Stimming [off-list ref] 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.