Re: [PATCH/RFC 00/17] Begin gettextizing Git

[Jonathan Nieder <jrnieder@gmail.com>]

Ævar Arnfjörð Bjarmason wrote:

> Or: git://github.com/avar/git.git gettextize-git-mainporcelain-v2

Is that against "next"?  For an RFC that's okay, but for a series
that will be part of a release it can be tedious to separate out
(not all topics in "next" necessarily are released, and "next"
traditionally gets rewound after each release).

Comments on the patches:

 Makefile: use variables and shorter lines for xgettext

The -o<whatever> passed to cc isn't usually included in CFLAGS,
and a part of me is similarly uncomfortable with including it in
XGETTEXT_OPTIONS.  Isn't that parameter something that should be
possible to change in the build system independently from the
user's XGETTEXT_OPTIONS preferences?

 gettext.c: work around us not using setlocale(LC_CTYPE, "")

The perror() problem shows up with strerror(), too, of course.
(perror just made for an easier demo.)

 gettext: Make NO_GETTEXT=YesPlease the default in releases

Copy-edits for the notes in INSTALL:

> +       - Git includes EXPERIMENTAL support for localization with gettext
> +         which is currently disabled by default in official Git
> +         releases.

s/EXPERIMENTAL/experimental/?  No need to shout.

I'd also s/currently // since this will not be current after a while.

> +         If you really want to build it you have to specify NO_GETTEXT=
> +         as a Makefile argument. If you're a downstream distributor
> +         please don't do so without consulting with the Git Mailing List
> +         first about the stability of this feature.

Similarly I'd s/really //.  If we want to dissuade people from trying
it out, we should probably do that with more explicit statements.

> +         It's only being included in releases so that source messages can
> +         be marked for translation without resulting in painful and
> +         inevitable merge conflicts between Git's pu branch and the
> +         rest. END WARNING.

Not sure what this means.  Maybe:

 The infrastructure is only included in this release to avoid
 complications in building other work on top of it.  If you turn
 it on, expect breakage.

> +         The primary target is GNU libintl, but the Solaris gettext
>           implementation also works.