On Thu, 10 Mar 2011, Ãvar ArnfjÃrà Bjarmason wrote: > On Wed, Mar 2, 2011 at 11:32, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > Piotr Krukowiecki <piotr.krukowiecki@xxxxxxxxx> writes: > > > 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 -- 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