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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ã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
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]