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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Aug 31, 2010, 18:08 UTC
Message-ID: <20100831180832.GQ2315@burratino>
In-Reply-To: <AANLkTinKgOdgTpORf-NSJ1wpURw9xOkQ3rXZvmV6XtBb@mail.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.