Re: [PATCH] Internationalization of git-gui

["Shawn O. Pearce" <spearce@spearce.org>]

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.