Re: [PATCH 000/160] [PULL] Update ab/i18n (again)

Ævar Arnfjörð Bjarmason venit, vidit, dixit 20.09.2010 22:37:

Please pull an updated ab/i18n. The version you have now should be
ejected in favor of it:

   git://github.com/avar/git.git ab/i18n
   http://github.com/avar/git/compare/87b5054...ab/i18n
   http://github.com/avar/git/compare/87b5054...ab/i18n.patch

Changes since last time, I can also send these to list on request. But
I don't think anyone wants a 160 patch flood:

    http://github.com/avar/git/compare/ab/i18n-in-pu...ab/i18n
    http://github.com/avar/git/compare/ab/i18n-in-pu...ab/i18n.patch

The Gist of it is:

  * I rewrote the huge monolithic commit that added NO_GETTEXT_POISON
    prereqs to tests out of the series and added these changes to
    individual tests instead. This was the practice I was using for
    patches later in the series, but I hadn't updated the earlier
    ones.

    In the process of doing that I found some tests that were
    mistakenly marked under NO_GETTEXT_POISON, mainly because the
    tests failed due to earlier tests that rightly had
    NO_GETTEXT_POISON. I did some re-arranging of test code to avoid
    this.

  * The PO files use line numbers again, and now have copyright
    notices at the top.

    It turns out that using msgmerge(1) is a major PITA without these
    line numbers, msgmerge will compeletely screw up merges that
    otherwise would have succeeded. E.g. it'll merge two similar but
    unrelated messages together and mark them as fuzzy, but if it has
    file/line number data it doesn't do this.

    Our PO usage is now completely standard, i.e. we're not removing
    anything that the normal GNU gettext tools add. I updated
    po/README to reflect this.

  * I did a msgmerge(1) on the existing PO files. This has left a lot
    of messages marked as fuzzy. TRANSLATORS: Please check if this has
    screwed up your translations.

Further notes below. But here's a diffstat between this series and the
one that was merged into pu:
    
     command-list.txt          |    1 +
     po/README                 |   43 +-
     po/de.po                  | 1220 +++++++++++++++-
     po/en_GB.po               | 2778 +++++++++++++++++++++++++++++++++++-
     po/hi.po                  | 2777 +++++++++++++++++++++++++++++++++++-
     po/is.po                  |   64 +-
     po/pl.po                  | 2788 +++++++++++++++++++++++++++++++++++-
     po/sv.po                  | 3492 +++++++++++++++++++++++++++++++++++++++++++++
     t/t0201-gettext-poison.sh |   36 -
     t/t0205-gettext-poison.sh |   36 +
     t/t1200-tutorial.sh       |    3 +-
     t/t2204-add-ignored.sh    |   45 +-
     t/t3700-add.sh            |   15 +-
     t/t5541-http-push.sh      |    2 +-
     t/t7004-tag.sh            |   27 +-
     t/t7500-commit.sh         |    3 -
     t/t7501-commit.sh         |    7 +-
     t/t7502-commit.sh         |   60 +-
     t/t7508-status.sh         |   63 +-
     wt-status.c               |    2 +-
     20 files changed, 13143 insertions(+), 319 deletions(-)
    

Jan Krüger (1):
  po/de.po: add German translation

Marcin Cieślak (1):
  po/pl.po: add Polish translation

Peter Krefting (1):
  po/sv.po: add Swedish translation

Ramkumar Ramachandra (1):
  po/hi.po: add Hindi Translation

Sam Reed (1):
  po/en_GB.po: add British English translation

Thomas Rast (1):
  gettext tests: locate i18n lib&data correctly under --valgrind

Ævar Arnfjörð Bjarmason (154):
  t7004-tag.sh: re-arrange git tag comment for clarity

Would it be possible to split the infrastructure part from the actual
translations, i.e. have two or more dependent branches (which is
probably easier than reordering on a single branch)?

I know at least one locale where we're actually in the early stages of a
fundamental discussion about translation principles. Blocking the whole
series because of that makes no sense.

Also, the set of reviewers for infrastructure parts will be quite
different from that for individual translations.

Michael