Quoting "Shawn O. Pearce" <spearce@xxxxxxxxxxx>:
Brett Schwarz <brett_schwarz@xxxxxxxxx> 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
-
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
