Блогчетање

php-gettext 1.0.9 is out: it integrates a number of fixes from different sources:

• E_STRICT fixes: these were most commonly reported.
• Improved plural forms handling: thanks to a patch by moeffju.net on the old tracker, plural form expressions should be now parsed in the similar way the regular C-based gettext parses them
• Allow live switching of languages for an already initialised translation domain, using a patch from eventum
• Provide fallback locale handling supporting standard GNU gettext locale names (eg. sr_RS.UTF-8@latin will try sr_RS@latin and sr@latin), inspired by another patch from eventum

With the endianness detection fix from 1.0.8, this should be a big step forward for everyone: 1.0.8 is simply a lower risk release with far fewer changes (just a fix for the most commonly reported bug). As far as I am aware, with 1.0.9, all of the users could switch back to using upstream php-gettext instead of their patched copy.

If not, I'd love to hear about it: ask a question or file a bug!

The common replacement for internal PHP gettext implementation which has flexibility of not depending on system-installed locales or gettext support being compiled in into PHP, has moved to Launchpad:

I've fixed the most annoying bug that's coming back depending on the architecture and every little change in PHP's handling of integers, and it should be now gone for good. That's available in the 1.0.8 release.

I also evaluated most of the patches/bug fixes from the old project page and a debian package, and integrated what still made sense.

I'll probably roll out another release soon which will include all the latest changes.

PHP-gettext, emulation of gettext functions is a very simple PHP library allowing usage of very popular gettext files and functions in PHP even if the appropriate library and/or locale is not supported on the system (web servers are known to have only a subset of locales one might need, and why should that limit web site owners on what language they are to offer to their users? or imagine testing on Windows? ;).

It's a very simple project, but the one I got most patches for! I never expected for it to be so popular, but it seems it's getting used in WordPress, Gallery, SquirrelMail, and probably many others (if you know a project which is using it, let me know, I like to brag about it ;).

And I've received a bunch of patches ranging from php-doc style comments, PHP4.4+ stream rewrites, entire emulation layer for standard gettext API, to caching rewrite of the core functionality.

Compared to xml2po, my other "big" free software project, it has received much more "media" coverage, and hey, xml2po is in Python (now, tell me Python is not a nicer language than PHP, I dare you! :). Not to mention that I have a similar reader in C#, (not) known as gettext#, but I don't know if anyone ever tried using that one :)

So, what's going on? Is it that PHP is so widely used, and php-gettext solved a widespread problem? Or simply that the code was simple enough to warrant enough contributors anyway?

Addendum: Oh, and a new version (1.0.6) is out, fixing all the known and reported bugs, and with all the new patches. Check the homepage!

First of all, a note to anyone who cares: PHP gettext was approved for hosting on GNU's Savannah. I also asked for it to be included in the GNU project, but I don't expect that to happen for various reasons (first of all, it requires PHP which itself is not a GNU project — though, one might argue that GNU gettext is a GNU project, and the goal for PHP-gettext is to add the same interface where GNU gettext is not available).

So, be sure to report any bugs, or send any patches. If you wish to download latest and greatest version, check PHP-gettext project page, and visit either the Files section for released tarballs, or CVS section for instructions on using CVS to fetch the development version.

I've also made some simple improvements in the code which increases performance in some corner-case situations (like reusing of same translation a number of times), but which won't help in general use-cases. If you've got any suggestions, be sure to send them over.

With the old PHP gettext, a stress test of reading in the same string for translation 10.000 times showed the following result:

real    0m23.302s
user    0m20.080s
sys     0m0.430s

Adding caching of already read in entries has improved the performance three-fold in this particular example (for 1000 reads, the improvement was two-fold, so this can be noticed only in rare occasions), as the following statistics show:

real    0m8.246s
user    0m7.340s
sys     0m0.150s

Wow, what an improvement in a case no one is going to come across? Wonderful! :-)

Did you ever have problems with the lack of gettext support on your hosting provider? I surely did.

Did you ever have problems with using system-set locales on your hosting provider (eg. imagine using a "sr@Latn" locale on a system which doesn't even have sane "sr" locales)? I surely did.

So, what's the solution? You either don't have the root access to the system, or you don't want to bother installing all the software and locales just to make translations happen.

Well, there was a "fallback" library for reading MO files (products of GNU gettext msgfmt tool) for a long time in standard Python distribution, but there was none for PHP (at least I couldn't find it).

There WAS none, but there is one NOW! It's called PHP-gettext (am I not inventive?), and you can grab PHP-gettext 1.0.1[1] from my hacks collection. It's published under GPL, so it's free software. It also means that there's no warranty, and that it at least

It's based on the description of MO file format in gettext info documentation. Doesn't provide all the background architecture of gettext proper, but it provides what you need most: using gettext() or _() calls, and using ngettext() calls. Oh yeah, it might be real slow for you — I didn't use it with project larger than 100 strings so far.

Some may consider it a feature, others may consider it a bug, but you can set the full path to the MO file that you want to read. This means that you have to take care of the administrativia of "gettext domains", "locales", etc. but in a sense where PHP is used, I consider it only a plus.

Anyway, check the lengthy README file (included) for all the details.

[1] There was a short-lived 1.0.0 version which is almost the same