Блогчетање

Данилово блогче

Tue, 01 Dec 2009

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!

[02:06] | [] | # | G | | TB

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:

php-gettext

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.

[01:24] | [] | # | G | | TB

Thu, 02 Feb 2006

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!

[20:58] | [] | # | G | | TB

Mon, 10 Nov 2003

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! :-)

[23:59] | [] | # | G | | TB

Thu, 23 Oct 2003

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

Works For Me!

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

[02:40] | [] | # | G | | TB
Contact
Danilo Segan

This is blog (web log) of Danilo Šegan (or Данило Шеган).

Archives
2017-Jan
2013-Dec
2011-Nov
2011-Oct
2011-Aug
2011-Jul
2011-Jun
2011-May
2010-Oct
2010-Aug
2010-Jul
2010-Apr
2010-Mar
2010-Feb
2010-Jan
2009-Dec
2009-Oct
2009-Aug
2009-Jun
2008-Oct
2008-Aug
2008-Jul
2008-Jun
2008-May
2008-Apr
2008-Mar
2008-Feb
2007-Dec
2007-Oct
2007-Aug
2007-Jul
2007-May
2007-Apr
2007-Feb
2007-Jan
2006-Nov
2006-Oct
2006-Aug
2006-Jul
2006-Apr
2006-Mar
2006-Feb
2006-Jan
2005-Sep
2005-Jun
2005-May
2005-Apr
2005-Mar
2005-Feb
2004-Dec
2004-Nov
2004-Oct
2004-Sep
2004-Aug
2004-Jul
2004-May
2004-Apr
2004-Mar
2004-Feb
2004-Jan
2003-Dec
2003-Nov
2003-Oct
2003-Sep
1983-Mar

< December 2009 >
MoTuWeThFrSaSu
  1 2 3 4 5 6
7 8 910111213
14151617181920
21222324252627
28293031   
Categories

Links
Kvota.net
Prevod.org
My study page
Srpski.org
GNOME
Friends' Blogs
alex (en)
bc (en)
Bojan Živanović (sr)
Carlos (en)
Goran (sr)
imp (sr)
lilit (sr)
Oskuro (en)
Zombie (sr/en)
Feeds
RSS