Re: Stable ab/i18n branch

> Jonathan Nieder <jrnieder@gmail.com> 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.

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

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