Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes: > On Sat, Feb 27, 2016 at 6:41 AM, Junio C Hamano <gitster@xxxxxxxxx> 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. -- 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