Christian Stimming <stimming@xxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
