Ãvar ArnfjÃrà Bjarmason <avarab@xxxxxxxxx> 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.
--
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