Adding gettext support to Git
I have an RFC patch series to Git to add gettext localization support to it. So that eventually you'll be able to configure Git to e.g. shout error messages at you in German. Won't that be a nice variant of the current abuse? I think so.
Here's the latest version of the patch series I posted to the Git mailing list.
For the Perl side of things (Git is partially implemented in Perl) I'm using libintl-perl's Locale::Messages. It was very pleasant to work with it. I wonder why more Perl projects don't use it instead of Perl-y libraries like Locale::Maketext.
Maybe it's just the GNU gettext dependency they're trying to get rid of, although libintl-perl includes a Pure-Perl version of the tools it provides .mo, so probably not.
Actually the way most open source projects do localization is "not at all". I don't blame them, I certainly can't be bothered most of the time. But I wonder to what degree we're losing potential users & contributors because of this.
There was a recent-ish study of social networks on GitHub where it was evident that a lot of Japanese Perl users had formed a social-ghetto amongst themselves. I've seen a few trending Perl repositories that only have README files in Japanese.
Maybe better localization tools - and most of all - a commitment to use them would help to bridge some of that.
Blogging about anything Perl-related I get up to.
One of the reasons could be that, unfortunately, even using Strawberry Perl (which is compiled using GCC), libintl-perl can't be installed on Windows.
Perl code is generally supposed to be cross-platform.
That's unfortunate, perhaps the
libintl-perldisto could be improved to cope with that, e.g. by falling back on the Pure-Perl implementation if the compilation fails.cpantesters was down when I wrote this, so I couldn't find what was preventing it from building on non-GCC. But presumably that's not an insurmountable problem either.
I maintain Locale::Maketext::Lexicon (I'm not the original author), and the xgettext.pl script makes it really easy to maintain your PO file.
It finds i18n'able strings in Perl code, Template Toolkit and Template Text templates, Mason, YAML and FormFu config.
It converts between the standard gettext syntax and Local::Maketext's syntax, which makes it easy to use with existing gettext translator tools, eg poEdit.
1. Locale::Maketext::Lexicon is broken -- it doesn't support plurals properly. Neither does xgettext.pl
2. XS version of Locale::Messages is incomplete and broken in different ways.
My advice: use libintl-perl's Locale::TextDomain with its PP part (you can select which one to use). It works acceptably good while staying compatible with the rest of the world.
Most important thing: learn what gettext can do for you by reading its own documentation
Shameless plug: I've written an article about i18n with Perl some time ago which covers most of the problems you might encounter: http://rassie.org/archives/247
Actually Locale::TextDomain is just a thin wrapper around Locale::Maketext. I'm using the latter in git because TextDomain makes a bunch of Perl module specific assumptions that were causing me more trouble to override than just using Locale::Maketext directly.
So Locale::Maketext like Locale::TextDomain will fall back on libintl-perl's Pure-Perl implementation of the XS one doesn't work.
And I've pretty much read the entire GNU gettext manual at this point.
I also read your article already (it came up on the Git list), it's very useful.
Actually, the module compiles on Strawberry Perl. The problem occurs when testing: it fails (badly) with a Perl crash.
So just keep in mind that, for now, whenever you use anything from libintl-perl, you won't be writing cross-platform code.
Hi Folks
I have another couple of references:
Giving CGI::Application internationalization (I18N) part1
Perl CGI::Application localization example
How does it crash? Nothing's cross platform when you first write it, the error libintl-perl is having on Windows is probably some solvable problem and not and inherent issue in GNU libintl or libintl-perl.
I actually just installed it on another Windows box (also with Strawberry Perl). So maybe the issue is a bit more complicated than that.
Maybe I just have two identically broken environments (for some reason). sigh