Re: What's cooking in git.git (Feb 2011, #06; Sun, 27)

From: Jakub Narebski <jnareb@gmail.com>
Date: Mar 10, 2011, 16:37 UTC
Message-ID: <201103101737.32237.jnareb@gmail.com>
In-Reply-To: <AANLkTikD2M=33B9E2mpBEmT5rLsZHPFc-T5Yqp3EMRJx@mail.gmail.com>

On Thu, 10 Mar 2011, Ævar Arnfjörð Bjarmason wrote:

> On Wed, Mar 2, 2011 at 11:32, Jakub Narebski <jnareb@gmail.com> wrote:
> > Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:

Show 10 quoted lines

> > > Don't know how it's handled in shell scripts or perl or whatever other
> > > language (which does not use gettext?)
> >
> > Both shell scripts and Perl scripts would use gettext: gettext.sh for
> > shell, Locale::Messages for Perl (we need lower level than Text::Domain,
> > and Locale::Maketext is first no longer recommended, and second does
> > not use gettext at least by default).
> 
> The i18n series uses Locale::Maketext:
> https://github.com/avar/git/blob/ab%2Fi18n/perl/Git/I18N.pm

If I remember correctly previous version (maybe a few iterations in the back) used Locale::Messages for Perl i18n, isn't it?

> What do you mean it's not recommended? There are some articles about
> Perl i18n saying you shouldn't use it, effectively because:
> 
>  * Building GNU gettext is hard, let's go shopping.

Git would use gettext for C and shell anyway, so this doesn't apply.

>  * There were some bugs in it, which do not apply to us.

   * Gettext support for plural forms etc. (ngettext) is better
     and easier to use for translators; Locale::Maketext requires one to
     be a programmer.

> So using it is fine. I might still write some Gettext::XS::Tiny module
> that works with both GNU gettext and Solaris, stick it on the CPAN and
> make us depend on it. It would more closely align with what we
> need. But that's something for the far future.

The Perl Journal article on using Locale::Maketext is supposedly outdated, see http://rassie.org/archives/247 (On the state of i18n in Perl) from 2009.

<blockquote>
  One basic, but fatal, mistake Maketext does is off-loading a lot of
  linguistic work onto programmer.

    * One particularly important point is the plural forms support ('1 apple',
      '2 apples'), which is important for many languages outside of USA and
      Western Europe . Maketext requires you to write a quant function that
      gets a string and a number as parameters and does some voodoo to
      produce the right string. Voodoo is undefined. In gettext it is --
      a formula for producing plural forms is defined which selects one of
      provided plural phrases.

    * No translator in his sane mind will ever write a Perl module for a
      language (they aren't programmers, remember?), the programmer will
      have to do it and will also have to understand the implications.

    * The quant notation ("Your search matched [quant,_1,document]!")
      foolishly assumes word order is the same in all languages.
      Implementing a quant method properly would require passing the whole
      sentence into the function and doing a complete linguistic
      transformation which is highly non-trivial and better done by human.

    * Most of those linguistic “conventions” like number formatting or
      plural forms do not change over time and can be compiled at one place.
      One such place is Unicode’s CLDR project, which also includes plural
      form building and number/date formatting among other country- and
      language-dependant data.

    * It can’t even be assumed that the translators actually know all of
      these conventions! They might assume they know them, but translator
      is not necessarily doing translations for a living, he might be a
      volunteer, like in most open source projects. Imagine what happens
      when an amateur translator explains the inner workings of his native
      language to a programmer?

</blockquote>

-- 
Jakub Narebski
Poland