<?xml version="1.0" encoding="UTF-8"?>
<!-- name="generator" content="pyblosxom/1.4.1 7/27/2007" -->
<!DOCTYPE rss PUBLIC "-//Netscape Communications//DTD RSS 0.91//EN" "http://my.netscape.com/publish/formats/rss-0.91.dtd">

<rss version="0.91">
<channel>
<title>Блогчетање   </title>
<link>https://danilo.segan.org/blog</link>
<description>Данилово блогче</description>
<language>en</language>
<item>
  <title>PHP-gettext 1.0.9 released</title>
  <link>https://danilo.segan.org/blog/ihatephp/php-gettext-1.0.9</link>
  <description><![CDATA[
<p>
  php-gettext
  <a href="https://launchpad.net/php-gettext/trunk/1.0.9"
     >1.0.9</a> is out: it integrates a number of fixes from different
  sources:
</p>

<ul>
  <li><code>E_STRICT</code> fixes: these were most commonly reported.</li>
  <li>Improved plural forms handling: thanks to a patch
    by <a href="http://moeffju.net">moeffju.net</a> on the old
    tracker, plural form expressions should be now parsed in the similar
    way the regular C-based gettext parses them</li>
  <li>Allow live switching of languages for an already initialised
    translation domain, using a patch
    from <a href="https://launchpad.net/eventum">eventum</a></li>
  <li>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 <a href="https://launchpad.net/eventum">eventum</a></li>
</ul>

<p>
  With the endianness detection fix from
  <a href="https://launchpad.net/php-gettext/trunk/1.0.8"
     >1.0.8</a>, 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
  <a href="https://launchpad.net/php-gettext">php-gettext</a> instead of
  their patched copy.
</p>

<p>If not, I'd love to hear about it:
  <a href="https://answers.launchpad.net/php-gettext/+addquestion"
     >ask a question</a> or
  <a href="https://bugs.launchpad.net/php-gettext/+filebug"
     >file a bug</a>!
</p>

]]></description>
</item>

<item>
  <title>PHP-gettext moved to Launchpad</title>
  <link>https://danilo.segan.org/blog/ihatephp/php-gettext-in-launchpad</link>
  <description><![CDATA[
<p>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 <a href="https://launchpad.net">Launchpad</a>:
</p>

<center>
  <a href="https://launchpad.net/php-gettext">php-gettext</a>
</center>

<p>
  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 <em>gone for good</em>.  That's available in the
  <a href="https://launchpad.net/php-gettext/trunk/1.0.8">1.0.8</a>
  release.
</p>

<p>
  I also evaluated most of the patches/bug fixes from the
  <a href="https://savannah.nongnu.org/projects/php-gettext"
    >old project page</a> and a
  <a href="http://git.debian.org/?p=users/metal-guest/php-gettext.git"
     >debian package</a>, and integrated what still made sense.
</p>

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

]]></description>
</item>

<item>
  <title>PHP-gettext: simple, yet popular?</title>
  <link>https://danilo.segan.org/blog/ihatephp/php-gettext-attracting-masses</link>
  <description><![CDATA[
<p><a href="http://savannah.nongnu.org/projects/php-gettext">PHP-gettext</a>,
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? ;).</p>

<p>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 <a href="http://wordpress.org/">WordPress</a>, <a
href="http://gallery.menalto.com/">Gallery</a>, <a
href="http://squirrelmail.org/">SquirrelMail</a>, and probably many
others (if you know a project which is using it, let me know, I like
to brag about it ;).</p>

<p>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.</p>

<p>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 <a
href="http://kvota.net/hacks/gettext-sharp">gettext#</a>, but I don't
know if anyone ever tried using that one :)</p>

<p>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?</p>

<p><strong>Addendum:</strong> 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 <a
href="http://savannah.nongnu.org/projects/php-gettext">homepage</a>!</p>

]]></description>
</item>

<item>
  <title>Improvements to PHP-gettext on Savannah</title>
  <link>https://danilo.segan.org/blog/ihatephp/improvements-to-php-gettext-on-savannah</link>
  <description><![CDATA[
<p>First of all, a note to anyone who cares: PHP gettext was approved
for hosting on <a href="http://savannah.gnu.org">GNU's Savannah</a>. 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 <strong>is</strong> a GNU project, and the goal for
PHP-gettext is to add the same interface where GNU gettext is not
available).</p>

<p>So, be sure to report any <a
href="http://savannah.nongnu.org/bugs/?group=php-gettext">bugs</a>, or
send any <a
href="https://savannah.nongnu.org/patch/?group=php-gettext">patches</a>. If
you wish to download latest and greatest version, check <a
href="http://savannah.nongnu.org/projects/php-gettext/">PHP-gettext</a>
project page, and visit either the Files section for released
tarballs, or CVS section for instructions on using CVS to fetch the
development version.</p>

<p>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.</p>

<p>With the old PHP gettext, a stress test of reading in the same
string for translation 10.000 times showed the following result:</p>
<pre>real    0m23.302s
user    0m20.080s
sys     0m0.430s
</pre>

<p>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:</p>
<pre>real    0m8.246s
user    0m7.340s
sys     0m0.150s
</pre>

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

]]></description>
</item>

<item>
  <title>PHP and Gettext playing nicely?</title>
  <link>https://danilo.segan.org/blog/ihatephp/php-and-gettext-playing-nicely</link>
  <description><![CDATA[
<p>Did you ever have problems with the lack of gettext support on your hosting provider? <em>I surely did.</em></p><p>
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)? <em>I surely did.</em></p><p>
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.</p><p>
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).</p><p>
There <em>WAS</em> none, but there is one <strong>NOW</strong>! It's called PHP-gettext (am I not inventive?), and you can grab <a href="http://kvota.net/hacks/php-gettext/php-gettext-1.0.1.tar.gz">PHP-gettext 1.0.1</a><a href="#footnote">[1]</a> from my hacks collection. It's published under GPL, so it's <a href="http://www.gnu.org/philosophy/free-sw.html">free software</a>. It also means that there's no warranty, and that it at least<div style="text-align: center"><em>Works For Me</em>!</div></p><p>
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.</p><p>
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.</p><p>
Anyway, check the lengthy README file (included) for all the details.</p><p>
<span style="font-size: small"><a name="footnote">[1]</a> There was a short-lived 1.0.0 version which is almost the same</span></p>
]]></description>
</item>

</channel>
</rss>
