Support (offered by community volunteers) > Internationalization and Localization

Prototype and benchmarks: using Drupal's t() for translating CiviCRM

(1/3) > >>

mathieu:
I did a quick test to manage CiviCRM translations in the Drupal database, rather than to use the gettext ".mo" files.

Background: I have noticed that crm_translate() can be fairly slow on many types of servers, especially if PHP "APC" caching is not used. You can see this if you trace a request using Xdebug. The cause may be that the translation file is big (1 meg) and has to be parsed on every request. However, managing translations in a database, as Drupal does, sounds less efficient since every translation string causes an SQL query.

So I wrote a small module to test this:

* https://github.com/mlutfy/civicrm_l10n
* get a copy using git: "git clone https://github.com/mlutfy/civicrm_l10n.git"

Then read the installation instructions in the README.txt (in short: enable the module, but also import the .po files into Drupal).

Conclusions:

* Benchmarks I did on a server with APC gave me aproximately 25-30% performance increase (although I have to admit my benchmarks were not the most scientific, so take with a grain of salt). I suspect that without APC the difference will be even more important.
* It's pretty useful to also be able to translation strings from custom Smarty templates or extensions.

I'd really like to get some feedback from other people: how it performs, whether the implementation makes sense.

Mathieu (bgm on IRC)

xavier:
Hi,

I completely missed that one. will try.

Any other feedback?

I'm really dubious that loading the transations from a db is faster than gettext, that is made for that, unless we do something not good with gettext.

Helmut did mention a couple of issues on the current implementation of gettext:
1) it loads all the strings even so a small part is used
2) it uses php functions even if faster/better native functions exists (was it about ml? no sure)

These are the points I vaguely remember, I might be wrong, but sounded like we could seriously improve the speed of that part.

Does it make sense for you?

X+

xavier:
Ok, so it turns out that
CRM/Core/I18n.php

isn't using gettext and the constructor seems to load all civicrm.mo indeed. I'm a bit confused as for how the others are imported.

Anyway, how do you benchmark? IMO going native if gettext is enabled is a big big win.

But we'd need to mesure.

mathieu:
* about benchmarking: I use php-xdebug and firebug (or "ab" aka "apache bench" in some cases). https://wiki.koumbit.net/XdebugEn

* native gettext: I think it would require the server to be correctly configured. i.e. if you want fr_FR, your /etc/locale.gen has to support it. (might be why your tests have not been successful). I'll give it a try.

mathieu:
@Xavier: Here's how to use native gettext:

* apply the patch (which is really just a quick test, do not use in production)

* rename your civicrm/l10n/fr_FR/messages.mo to civicrm/l10n/fr_FR/LC_MESSAGES/civicrm.mo

IMPORTANT: your operating system locale must support the language. On Debian/Ubuntu, "dpkg-reconfigure locales". Also check /etc/locales.gen.

EDIT: use patch2

Navigation

[0] Message Index

[#] Next page