Re: [RFC/PATCH] i18n: add infrastructure for translating Git with gettext

[Jakub Narebski <jnareb@gmail.com>]

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> = Perl
> 
> Perl code that wants to be localized should use the new Git::I18n
> module. It imports a __ function into the caller's package by
> default.
> 
> Instead of using the high level Locale::TextDomain interface I've
> opted to use the low-level (equivalent to the C interface)
> Locale::Messages module, which Locale::TextDomain itself uses.

Nice of you using libintl-perl instead of old Locale::MakeText
(with gettext compatibility layer).

> See <AANLkTilYD_NyIZMyj9dHtVk-ylVBfvyxpCC7982LWnVd@mail.gmail.com> for
> a further elaboration on this topic.

http://thread.gmane.org/gmane.comp.version-control.git/148446/focus=148478

> = Shell
> 
> Shell code that's to be localized should use the git-sh-i18n
> library. It's basically just a wrapper for the system's gettext.sh.
> 
> If gettext.sh isn't available we'll fall back on gettext(1) if it's
> available. The latter is available without the former on Solaris,
> which has its own non-GNU gettext implementation. We also need to
> emulate eval_gettext() there.
>
> If neither are present we'll use a dumb printf(1) fall-through
> wrapper.
> 
> I originally tried to detect if the system supported `echo -n' but
> I found this to be a waste of time. My benchmarks on Linux, Solaris
> and FreeBSD reveal that printf(1) is fast enough, especially since
> we aren't calling gettext() from within any tight loops, and
> unlikely to ever do so.

Didn't we decide that the only sane way to handle eval_gettext
is to provide minimal implemetation in the form of external command?
 

Thanks for working on this.
-- 
Jakub Narębski