Junio C Hamano venit, vidit, dixit 19.10.2010 01:39: > Ã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. I'd just like to second (or third or..) Junio's points here since I had suggested a split like that earlier already, and I think the current state of affairs simply makes many potential reviewers (at least one that I know of) go away. 1.,2. and (maybe to a lesser degree) also 3. should be able to find many reviewers, thus making the potentially problematic parts as solid as possible. (I'm still waiting for a conceptual approach to 4., i.e. glossary first, but that is a different issue.) Michael -- 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