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
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
Stefan Nagtegaal wrote:
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/).
Yes, I know this work.
He told me it would tremendously speed up things,
That is what I was trying to verify, but without luck.
and would made module-specific translations possible.
That's true, but the module would need to specifically set the domain of the translation. This would be incompatible with our current locale module.
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!
If somebody has numbers that show that the speed increase is higher than the maybe-5% that I observed then I am happy to look at it again. Cheers, Gerhard
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
Gabor Hojtsy wrote:
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?
The point would have been to support the gettext stuff as well as the native Drupal db cache.
Push the database based translation support into contrib and support a mo file based engine in core?
Support .mo files through gettext extension in core.
Or add a t() API? :) Requiring the gettext extension without an alternative is IMHO not an option.
I've never proposed that.
Providing a significantly more efficient but PHP configuration dependent engine could be a good idea though.
That was the idea, but apparently the efficiency gain isn't all that big. Cheers, Gerhard
participants (4)
-
Gabor Hojtsy -
Gerhard Killesreiter -
Karoly Negyesi -
Stefan Nagtegaal