Re: [PATCH 00/22] Mark more strings for translation

[Junio C Hamano <gitster@pobox.com>]

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

> On Sat, Feb 27, 2016 at 6:41 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> In previous cycles, I often left many topics in 'next' when tagging
>> this zero-th preview, but eventually merged them before the final.
>> I decided to do things a bit differently for this cycle: a topic,
>> once it hits 'next', will not be rewound and only refined and
>> corrected with incremental updates, so the only effect such a late
>> merge to 'master' before the final is that some topics are not as
>> widely tested on 'master' before the final one is tagged.
>>
>> So this -rc0 is deliberately aggressive in that it includes all
>> topics that have been cooking in 'next' that I think we can fix bugs
>> that might still lurking in them before the final (it merges 25
>> topics since the last batch to 'master').  The topics not merged to
>> this preview, on the other hand, will not be considered for 2.8
>> final, even though I might later succumb to the temptation to pick
>> up ones that are in 'next' as of today ;-)
>
> Beautiful. This allows me to fix up all i18n strings in a single
> series instead of spreading them across many topics in 'next'.

Thanks.  "A new string we added since v2.7.0 that is not marked for
i18n" is a new i18n bug and "a string that used to be marked is not
marked when the code was rewritten since v2.7.0" is an i18n
regression, and we would want to "fix" both post -rc0 period.  The
patches that touch new strings added since 1.7.x are exactly that ;-)

We'd still want the fixes to apply on top of relevant topics if we
could, as the fix to the topic itself (with or without i18n fixes),
when we discover that it has a huge flaw not desirable in v2.8.0,
might be to revert the whole thing, though.

> I'm not
> sure if there's enough time for translators before release though.

Also we need to get an Ack from the authors of commits we added in
this cycle that these patches fix i18n bugs they introduced and make
sure there is no "this i18n mark is not appropriate as it is a
plumbing output (or protocol messsage) that should not be
translated" response from them.  It won't be like I apply these
blindly today and ask translators to start working.

> This series marks many strings for translation. It's a result of
> looking for new strings between 1.7.2 and 'master', and sometimes
> looking around touched files some more.
>
> Most of these are wrapping _() around strings, except 01/22 (enable
> gettext) and 20/22 and 21/22, which convert some more strings (they
> have been in my queue for a year)
>
>   [01/22] credential-cache--daemon: enable localized messages
>   [02/22] builtin/blame.c: mark strings for translation
>   [03/22] builtin/checkout.c: mark strings for translation
>   [04/22] builtin/clone.c: mark strings for translation
>   [05/22] builtin/config.c: mark strings for translation
>   [06/22] builtin/config.c: mark strings for translation
>   [07/22] builtin/update-index.c: mark strings for translation
>   [08/22] convert.c: mark strings for translation
>   [09/22] credential-cache--daemon.c: mark strings for translation
>   [10/22] http.c: mark strings for translation
>   [11/22] ident.c: mark strings for translation
>   [12/22] notes.c: mark strings for translation
>   [13/22] ref-filter.c: mark strings for translation
>   [14/22] refs/files-backend.c: mark strings for translation
>   [15/22] remote-curl.c: mark strings for translation
>   [16/22] run-command.c: mark strings for translation
>   [17/22] sha1_file.c: mark strings for translation
>   [18/22] submodule.c: mark strings for translation
>   [19/22] trailer.c: mark strings for translation
>   [20/22] transport-helper.c: mark strings for translating
>   [21/22] transport.c: mark strings for translating
>   [22/22] wrapper.c: mark strings for translation
>
> Total 20 files changed, 385 insertions(+), 372 deletions(-)

Let's queue this and start cooking; I see you never To'ed the guilty
party that introduced i18n bug/regression to each of your patch, but
can you start pinging them to collect Acks?

Thanks.