Re: Stable ab/i18n branch

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 18, 2010, 23:39 UTC
Message-ID: <7vmxqb2hqk.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTikc80ev+ex6-9RDgO_h-4LEuZf6M9hPAfVQ9oSX@mail.gmail.com>

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

Show 8 quoted lines

> 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.