Op 10-jun-2006, om 22:24 heeft Gerhard Killesreiter het volgende geschreven:

Hi there,

IIRC there has been speculation that using the gettext object files (.mo files) for storing translations instead of the database would be a lot faster. Unfortunately, I can not confirm this. It seems to be somewhat faster but not that much that I'd consider the inclusion of such a feature worthwhile. The configuration is rather awkward and error prone.

Cheers, Gerhard

Gerhard, I had such a discussion some time ago with "Axel". You can see some of his work with using Gettext with Drupal in his sandbox (http:// cvs.drupal.org/viewcvs/drupal/contributions/sandbox/axel/gettext/). He told me it would tremendously speed up things, and would made module-specific translations possible. i hope you could re-(over)think this once again. You were probably already aware of the code inside Axels sandbox, but I hope you'll make some progress on this feature which is really in my kind of interest (as you also know ;-)). Hope to hear more about this soon! Steef

Gerhard Killesreiter wrote:

IIRC there has been speculation that using the gettext object files (.mo files) for storing translations instead of the database would be a lot faster. Unfortunately, I can not confirm this. It seems to be somewhat faster but not that much that I'd consider the inclusion of such a feature worthwhile. The configuration is rather awkward and error prone.

If this requires the gettext module turned on in PHP, then what is the point? Push the database based translation support into contrib and support a mo file based engine in core? Or add a t() API? :) Requiring the gettext extension without an alternative is IMHO not an option. Providing a significantly more efficient but PHP configuration dependent engine could be a good idea though. Goba