On Sun, Oct 17, 2010 at 04:44, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
>
>> Ãvar ArnfjÃrà Bjarmason wrote:
>>
>>> Could you please pick up the 160 commit version of this at:
>>>
>>> Â Â git://github.com/avar/git.git ab/i18n
>>
>> This is a "give an inch and they'll ask for a mile" sort of thing, but
>> would it be possible to maintain a stable branch with the i18n
>> infrastructure that only gets rebased when there is reorganization
>> going on?
>
> People might have noticed that I've refrained to take other topics that
> may add new messages to 'next'. ÂI would wanted to merge ab/i18n early in
> the cycle soon after dust has settled after 1.7.3 release. ÂAnd I still
> do.
Good to hear. I didn't know that before, and that's really all I
wanted to know.
> Having said that, there are different classes of risks associated with
> i18n effort.
>
> (1) Regressions that even hit a NO_I18N build.
> (2) Regressions that hit LC_ALL=C execution in a !NO_I18N build.
> (3) Regressions that hit plumbing run in a non-C locale.
>
> Â. i18n needs not just marking strings with _("string") but also needs to
> Â fix code that manually formulates messages by series of strcat(). ÂIt
> Â may need to start using allocations on the heap, with potential risk of
> Â usual bugs (leaks, use-after-free, etc.) and performance degradation.
>
> Â. Messages left unmarked with _("string"), or messages that are marked
> Â with _("string") that shouldn't have, won't be serious issues for the
> Â first two classes. ÂThe latter is a serious regression for the
> Â plumbing.
>
> We are all human, and misconversion during this process is possible, even
> though the above classes of regressions are unacceptable. ÂOn the other
> hand, as long as the above three classes of regressions are minimum and
> quickly fixed/fixable, issues in non-C locale Porcelains are tolerable
> during the initial cut.
>
> I've looked at the patches in the series, and plan to take another look.
> I'm sure others on the list have checked the series, some with fine combs,
> too, and hopefully Ãvar has fixed any such regression that has been
> reported and plans to do so for the ones discovered in the future. ÂAs
> long as we are sure that we have done a reasonable effort to eyeball the
> patches, the logical next step would be to merge the series to 'next' for
> further testing.
Right. I'll have time to deal with any bugs that crop up, and I'm
reasonably sure it's OK as-is.
> (4) Incomplete *.po file, and languages without *.po file.
>
> Once we are sure that the series does not have the first two classes of
> issues, we can ask everybody to mark new strings in their series, iow,
> merge the i18n part to 'master'. ÂIf we can do that sooner, it would be
> better, and we do not need specific l10n part from the series during that
> stage.
>
> A language that already has *.po file may lack necessary translation;
> there may be languages that do not have *.po file. ÂThey can be added with
> a lot smaller risk later without unstabilizing the codebase.
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?
That could be done, but just merging the whole 160 patch series and
turning it off by default would have pretty much the same effect. And
since I thought this was going to get merged soon-ish anyway I didn't
spend time on something like that.
> So where are we now? ÂI think a constantly rebased 160-patch series that
> has infrastructure bits and l10n bits mixed together is not very friendly
> to review for the first three classes of regressions (which are all I care
> about at this point) to help the series hit 'master' sooner.
I think we're basically at a point where merging it down to next ->
master is the logical next step.
> In any case, the branch merged to 'pu' has been replaced with the tip of
> the said branch from Ãvar's repository now.
Thanks.
--
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