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 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