Very fast t() for a small set of strings

subscribing. something like this would be fantastic for ecommerce project.

patch contains cruft.

I am wondering if it would be worthwhile to move the result of the variable_get test into a static var considering that t() is called very often.

Rerolled without tabs.

As we cache clean_url inside url() so should we cache this variable inside t(). Way, way too many calls to t() to allow for another variable_get.

To avoid losing a little performance for busy translated sites, could you check for locale() before checking for $t_pairs?

Grumble, grumble. count is slower than empty, leaving out isset causes notices.

@sime - that would avoid one call to variable_get() which is extremely fast. no need to over engineer here.

@chx - thanks for reroll and reminder about speed.

can someone please test this and move along to RTBC is you are satsfied. in order to test, just uncomment the t_pairs item and $conf lines in

mw_9.patch has 2 side-effects.

1. If you set any pair in t_pairs then you cannot translate anything else because it returns the preset value or the untranslated $string value.
2. Placeholders(@count, ...) do not work.

I have attached a new patch that avoids these side-effects.

Great idea, this would also be fantastic for buddylist module. I can't see any functional problems with the latest patch.

Small semantic note: should 'else if' be 'elseif'? Other than that great.

Yeah, a couple things...

• else if needs to be elseif.
• comments need to wrap at 80 chars.
• "t_strings" is not a good name for this variable... unlike "site_name" and "theme_default" which are very intuitive, "t_strings" provides no indication of what that variable is for (the vast majority of Drupal users know nothing of the t() function). How about something like 'custom_text' instead?

That having been said, a huge +1 for this functionality! :)

I aggree that t_pairs is not descriptive enough. custom_text may be a better choice but I would like to see a variable name which indicates that it holds translations. I cannot find a good name right now but it should be something like custom_translation. And one thing that you may not notice is settings.php file must be edited with a UTF-8 capable editor. We might put a warning before the $conf array.

BTW, I was trying to add sample translations into the settings.php for two languages and I think this is not a good way to do this. The array structure and => operator is not so easy and people can break their site. Can we provide the same functionality in an easier way?

I couldn't tested the attached patch, I apologize if it does not work.

I put a warning in the settings.php file but I forgot to save it using utf-8 so you can see ? characters in the sample translation.

I am attaching the same file saved in utf-8. This is one reason of why we should seek for another way of managing translation overrides.

I agree that this functionality may be limited to English to keep it simple and fast. It doesn't help that much for other languages. If we all agree on that this functionality is only available to English, than it is OK to use settings.php, but don't use 'en' key since it is confusing.

I created a new seperate code region in settings.php for string override. Please review the patch.

This is getting _really_ pedantic now, but "texts" is not a proper English word; it should be just "text" and be referred to in singular rather than plural.

I would re-roll myself but am juggling 200 things atm.

Here's a reroll that uses "$custom_strings" rather than "$custom_texts" and clarifies a few of the code comments.

Fix a missing period in a comment.

+1 for the functionality, it adds some interesting options.

However, I'd like to be able to use it for other languages.

My use case for this: small site, not English, limited functionality for site visitors, when you only need to use a small number of translated strings. I'd like to be able to save all the performance cost that locale module introduces, and wouldn't mind about some English strings for site admins only.

So why don't we forget about checking for 'English', and better, use some variable like "custom_strings_$language->language" ??

Rerolled to remove offset.

@moshe: You said you would move the customer UI for this out of settings.php to a form. Did you had time to work on this? I'm very interested in that feature and would like to provide help.

Just reviewed the patch. Seems like a rather hackish way to speed things up... But I don't know a better way if you are into getting rid of locale module in your project. I don't see a reason not to support Jose's ideas here, although it is a very small segment, where you set up sites with a really dumbed down Drupal (like a small forum site or something), and need translation that way.

Modified patch attached (although not tested). It should have very similar performance impacts on both English and foreign language sites as the patch before, we just cache the strings in a two dimensional array. I also modified the variable naming, so developers know what the heck are those custom strings.

Handing to Dries for decision, as I am not entirely confident that this feature should be in Drupal.

A big +1 for this patch. Like path aliasing, it's a potential performance hot-spot. Giving developers and site maintainers the ability to 'fast-track' specific t() strings is an important improvement.

OK, read through the all the support notes on the patch, simlified my last version, and landed that patch in core. Now t() caches in one associative array, because it has no notion of translating to multiple languages in the same request (yet), so that change should be for a different (larger scale) patch. Thanks to everyone who participated.

http://drupal.org/cvs?commit=66313

Ooh! I just came across this. Thanks everyone.

How many strings is "a small set of strings"?

The locale module working with the SQL backend was also improved lately, so there is a smaller cache used and the lookups are quicker (we look at smaller data sets too in the database). :)

subscribe

Hi,

I've created a 5.x version of this patch, since I needed it.
Is anybody interested?

Basically, in common.inc, DELETE:

if (function_exists('locale') && $language->language != 'en') 

And put this instead:

  static $custom_strings;
  if (!isset($custom_strings)) {
    $custom_strings = variable_get('locale_custom_strings_en', array());
  }
  // Custom strings work for English too, even if locale module is disabled.

  if (isset($custom_strings[$string])) {
    $string = $custom_strings[$string];
  }

  // Translate with locale module if enabled.
  elseif (function_exists('locale') && $language->language != 'en') {

Then, in your settings.php, you can have:

$conf['locale_custom_strings_en'] = array(
   'Email this page'      => 'Email',
   'Add new comment'      => 'Discuss',
   'Add new comment'      => 'Discuss',
   'Best published scoops' => 'This week\'s highest ranked',
   'Best upcoming scoops' => 'Highest ranked upcoming',
);

Since I don't think there will be D5.4, I am not bothering with a patch. But, the good thing about this change is that it will be compatible with D6... so, feel free :-D

Bye,

Merc.

Bump. Can the above make it into the next 5.x release?
With the 6.x code committed, this backport would allow many of us who will continue to follow 5.x on production sites to officially begin to use a feature that 6.x will continue to support, rather than use locale hacks (or worse) just to change a few strings.

Yes, I realize it's a simple change and we could roll our own, but some of us work in production environments where core patching isn't allowed unless critical or security related.

Features are not added to stable releases.

Hi,

Also, my patch above (which I use and I consider absolutely necessary to my Drupal installation) is just not quite production-ready... You'd need to make it a little configurable (that variable_get('locale_custom_strings_en', array()); is an eyesore) etc.

It's not really worth it, with D6 coming out soon... But it's cool to have it nevertheless :-D

Merc.

Moshe pointed me to http://drupal.org/project/stringoverrides which implements this for 5.x

Hi,

sethcohn, moshe:

*** WOW ***

What a fantastic module!

Merc.

Hi,

On a multi install Drupal 6 strings are changed on the second installed website but not on the first one, anybody has met this trouble ?

Thanks.

Any idea why changing stirngs in settings.php doesn't work on multi install websites ?

Thanks.

@wwwoliondorcom I tried this on a basic installation in 6.14 with two sites and it worked as I expected. i.e., only changed on one site. One idea is to make sure you're adding it to the correct settings.php file.

Since settings.php files are specific to each site on a multi-site install, it'll only affect one at a time. To affect them all, you'd have to edit each settings.php file.

Thank you, but I tried any possibility, and even when changing both Settings.php it still doesn't work on SOME of my multi installs, but working on others.

I don't know where to look now.

Thanks again.

Hi,

So nobody has met the same problem as me on a multi install Drupal 6 ? (only one website translates)

Thanks.

...never mind me.

...sorry for the noise.