Re: Stable ab/i18n branch

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Do you mean to re-arrange it so that there's a patch at the front of
> the series that introduces gettext.h with only the fallbacks:
>
>     #define _(s) (s)
>     #define N_(s) (s)
>
> And then merge the ~120 gettextize patches first and do the
> infrastructure later?

Not really.

Two pieces that would be nice to have in 'master' (or even 'maint', if we
consider avoiding merge conflicts and mismerges when fixes are queued
there) are:

 1. preparatory fixes to code that builds message string by concatenating
    parts of speech in English word ordering into buffer or emitting to
    output stream piece by piece; they should convert them to some form of
    sprintf-like format strings plus arguments.  This does not necessarily
    have to mark the format strings with _(s).

 2. the empty definitions for _(s) and N_(s).

I would consider the first one part of general clean-up job, which we know
will help i18n, but which we would want to do regardless of i18n.  And it
is probably the most error prone part in the whole process.  The sooner
the result of these two steps hit 'master', the less pain for everybody.

And then:

 3. actual marking of strings with _(s) and N_(s).

which can be merged to 'next' after vetting for regression (the first two
classes).

 4. Adding and polishing of *.po files for actual messages and languages,
    i.e. l10n.

This can happen pretty much independently from 3.  Honestly I would be
happier if I do not have to keep track of the actual l10n part.

I think the current series to some degree conflates steps 1. and 3.  As
the list of risks I outlined in the previous message show, mistakes in 1.
is much more grave than mistakes in 3. (iow, no big deal for having a few
untranslated messages during early rounds of i18n support); I would have
preferred these two steps were clearly separated, so that we can push the
first two steps out to the 'master' sooner.