Improving Drupal performance using native gettext for translations

String translation issues concern the Locale queue: changing component accordingly.

Drupal and Gettext related comments:

1. To make Drupal use alternate methods of lookup, Drupal usually does variable_get('locale_use_gettext', FALSE) like settings. Then settings.php can modify $conf['locale_use_gettext'] or there can be a UI to set these. With your global variable approach that does not work.

2. Drupal allows for arbitrary language translations. For example, contact module can send 3 emails in one HTTP request in 2 different languages. Therefore initializing the system for language and then considering it done does not work. The language requested needs to be obeyed.

3. Drupal supports the gettext standard context specification. PHP does not seem to support that. Very unfortunate I must say for this patch. Because Drupal will just request t('View') and whether that is a verb to view something or a noun to refer to a views view or a noun to refer to some other type of view is provided by the context. Same applies to "May". It can be a short month name, a long month name or other things. Gettext certainly support this and we want to expand on this in Drupal 8 even more, so looks like PHP has a serious limitation here. At worst you could mimic this by having different text domains per context and then switch between them as needed, but that sounds pretty hackish.

4. Drupal uses t() indirectly form format_plural() as well to look up strings. For your solution to work, you'd need to abandon actually using the plural syntax in gettext for those strings, and use Drupal's workaround to support string level lookups. I assume this might be in your converter script, is it?

+    putenv('LANG='. $lang_code);
+    setlocale(LC_ALL, $lang_code);

The Gettext extension has been in PHP for ages. There is a reason we are not using it: it is utterly broken. The Gettext extension:

• relies on an environment variable which is set *per process* (and thus completely broken in any multi-threaded SAPI),
• and relies on the system locales: a language that is not configured on the server will not be loaded by Gettext

As a consequence, this ties Drupal to the server environment which is completely unacceptable. A few years back I wrote some code to read strings from .mo files directly, but it turned out less efficient then querying the database (especially since we cache small strings).

A lot of things can be done to improve the performance of locale() (especially coming up with a better caching strategy), but using the Gettext extension is not one of them.

setlocale(LC_ALL, $lang_code); is one of the most horrible, horrible things you could ever do. This is the source of many, many problems like converting database default float values of '0.8' to '0,8' which then creates invalid SQL.

Dave: it's possible to fix it using LC_MESSAGES instead of LC_ALL for setlocale()

Damian: I think your second point isn't right. It's not an issue but a requisite. I mean, if you want to use cleanpaths on your Drupal, yo need to install mod_rewrite, so if you want to use improved internationalization for your Drupal (more performance) you need to install those languges for gettext on your server (it's not critical since you can use the current locale system -and not select the other one-).

About the first point from your comment, I think we can discuss some workarounds to get clues and solve the problem. Don't you?

Both of my points are very valid. If you are ready to prove me wrong, do it. But for me this is definitely a won't fix.

We can try and make t() or locale() replaceable in some way like the cache system or the mail system if there is enough interest and we can make it work without much performance problems on out of the box sites however, no?

Getting the translation subsystem properly pluggeable is in the scope of all the other issues (#361597: CRUD API for locale source and locale target strings and friends).

Well, I don't think regular API changes will make that possible since we are very wary of putting more logic in t() due to the performance impact it has. It would be very easy to fix this by putting in a general lookup hook that contribs can hook into and provide the string before we look in the db, but that would (probably unnecessarily) degrade performance for out of the box sites, so...

Now that I'm thinking of it, if someone can serialize an ArrayObject (http://php.net/manual/en/class.arrayobject.php) into a locale_custom_strings_$langcode variable, then they can do this pretty much in Drupal 7 contrib, because the array lookup is always attempted. Sounds like a possible but very hackish solution, isn't it :)

Sub. (A PHP : Gettext implementation would be really great).

@pounard: from what it looks like #1213510: A modern t() would be able to enable it for a contributed module to do it.

Probably ArrayObject comes to core #402896: Introduce DrupalCacheArray and use it for drupal_get_schema()