[PATCH 00/22] Mark more strings for translation

[Nguyễn Thái Ngọc Duy]

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

[Duy Nguyen]

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]

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

[Junio C Hamano]

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

[Nguyễn Thái Ngọc Duy]

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