[PATCH 00/22] Mark more strings for translation
I originally wanted to have a look regularly at what's in 'pu', catch translatable strings that are not marked so and ask for updates. But I failed horribly at that, so for this cycle I just looked at all the changes between the last release and master and marked strings. This series probably won't end up in 2.18 because now is probably too late for big changes, which is fine. Nguyễn Thái Ngọc Duy (22): archive-tar.c: mark more strings for translation archive-zip.c: mark more strings for translation builtin/config.c: mark more strings for translation builtin/grep.c: mark strings for translation and no full stops builtin/pack-objects.c: mark more strings for translation builtin/replace.c: mark more strings for translation commit-graph.c: mark more strings for translation config.c: mark more strings for translation connect.c: mark more strings for translation convert.c: mark more strings for translation dir.c: mark more strings for translation environment.c: mark more strings for translation exec-cmd.c: mark more strings for translation object.c: mark more strings for translation pkt-line.c: mark more strings for translation refs.c: mark more strings for translation refspec.c: mark more strings for translation replace-object.c: mark more strings for translation sequencer.c: mark more strings for translation sha1-file.c: mark more strings for translation transport.c: mark more strings for translation transport-helper.c: mark more strings for translation archive-tar.c | 12 +-- archive-zip.c | 14 ++-- builtin/config.c | 48 +-- builtin/grep.c| 12 +-- builtin/pack-objects.c| 108 - builtin/replace.c | 90 ++--- commit-graph.c| 20 ++--- config.c | 76 +- connect.c | 87 ++-- convert.c | 42 +- dir.c | 8 +- environment.c | 4 +- exec-cmd.c| 2 +- object.c | 10 +-- pkt-line.c| 26 +++--- refs.c| 40 +- refspec.c | 2 +- replace-object.c | 6 +- sequencer.c | 26 +++--- sha1-file.c | 110 +- t/t0021-conversion.sh | 2 +- t/t1305-config-include.sh | 2 +- t/t1308-config-set.sh | 2 +- t/t1400-update-ref.sh | 20 ++--- t/t1404-update-ref-errors.sh | 4 +- t/t1450-fsck.sh | 2 +- t/t3005-ls-files-relative.sh | 4 +- t/t3210-pack-refs.sh | 2 +- t/t3310-notes-merge-manual-resolve.sh | 6 +- t/t5500-fetch-pack.sh | 2 +- t/t5505-remote.sh | 2 +- t/t5512-ls-remote.sh | 2 +- t/t5570-git-daemon.sh | 6 +- t/t5801-remote-helpers.sh | 8 +- t/t7063-status-untracked-cache.sh | 2 +- t/t7400-submodule-basic.sh| 2 +- transport-helper.c| 89 ++--- transport.c | 18 ++--- 38 files changed, 466 insertions(+), 452 deletions(-) -- 2.18.0.rc0.309.g77c7720784
Re: [PATCH 00/22] Mark more strings for translation
On Sun, Feb 28, 2016 at 12:34 AM, Junio C Hamano wrote: > 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. Urgh.. if there are only a handful of topics (like in 'pu' and 'next' now), I could go identify author/series manually. But there are 118 topics since 2.7.2 and my series changes about 300 strings. Hold on tight, let me write something that blames based on diff... -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/22] Mark more strings for translation
Junio C Hamano writes: > 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 ;-) Oops, I meant 2.7.x here, not 1.7.x. >> 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. And I hope you meant 2.7.2 here, too. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/22] Mark more strings for translation
Nguyễn Thái Ngọc Duy writes: > On Sat, Feb 27, 2016 at 6:41 AM, Junio C Hamano 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/22] Mark more strings for translation
On Sat, Feb 27, 2016 at 6:41 AM, Junio C Hamano 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'. I'm not sure if there's enough time for translators before release though. It depends on how many rc- there are and how long it takes for this series to graduate. 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(-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
