[El Forum]

[eluser]Yoglets[/eluser]
This post is my solution to the question I posed here: http://ellislab.com/forums/viewthread/56508/

I made a very simple mod to Parser.php:

Code:

--- Parser.php.orig     2007-07-16 17:22:46.000000000 -0500
+++ Parser.php  2007-07-16 17:23:14.000000000 -0500
@@ -47,6 +47,11 @@
                $CI =& get_instance();
                $template = $CI->load->view($template, $data, TRUE);

+               foreach ($CI->lang->language as $key => $val)
+               {
+                       $data['_(' . $key . ')'] = $val;
+               }
+
                if ($template == '')
                {
                        return FALSE;

This simply adds a special coded entry to the existing $data array for each entry in the language array. Thus, instead of having to use a template with this:

Code:

<?=$this->lang->line('string')?>

Or having to explicitly map this value to your $data array in your controller like this:

Code:

$data['string'] = $this->lang->line('string');

One can simply use this in the template:

Code:

{_(string)}

[El Forum]

[eluser]sikkle[/eluser]
Is it a good way to do this people ?

[El Forum]

[eluser]Phil Sturgeon[/eluser]
Tis a good plan but not a very friendly tag type ey?

I'd preffer to have something like:

Code:

{lang:key_name}

or something similar.

Also the way in which you do this aint the best way to achieve it. You may want to do some clever preg matching and calling of specific language lines based on matches in the file, NOT just shoving EVERY loaded language file into every view. This will have a bit of a hit on performance, and even if its only minimal its not good practise.

[El Forum]

[eluser]Yoglets[/eluser]
Well, the "_($key)" notation mimics the widely used short alias for PHP's gettext() function, so I figured it was already commonly known by anybody using multiple languages in PHP. If not, I can just add custom delimiters similar to the $l_delim and $r_delim that are already defined in the Parser class. For example:

Code:

var $l_lang_delim = '_(';
var $r_lang_delim = ')';

Then the added code simply becomes:

Code:

foreach ($CI->lang->language as $key => $val)
{
    $data[$this->l_lang_delim . $key . $this->r_lang_delim] = $val;
}

So if you don't like the _() notation, you can just change it to whatever you prefer.

Regarding the comment about only adding keys that actually get used in the template... aren't you (for the most part, at least) already going to have only the keys you actually need for that one particular view loaded? I.e., you shouldn't be loading keys you're not using.

Regardless, a failed str_replace() is much faster than a failed preg_match(), so looking through the template once for each key in an effort to remove the unused ones will be slower than just trying to replace those keys that don't exist. (Benchmarked with my particular view and language strings, trying to remove the unused keys before parsing the template actually makes the entire process 62% slower. Using strpos() instead of preg_match() is much better (10% slower), but still not better than simply doing nothing.)

[El Forum]

[eluser]Phil Sturgeon[/eluser]
You are missing the point I feel. You dont look through the templare for each key, that will of course be slower/as slow as just throwing every variable in.

Im talking about a find/replace solutuion that activly seeks your languag tags. I was thinking instead of the tags you have, to search for any variable that ends in _lang} (but could be any tag, its very unimportant) as this would be a very smart way fo doing it. This would in fact be faster as it is one simple preg_match compaired to one for many.

[El Forum]

[eluser]Yoglets[/eluser]
Ah ok I see what you're getting at. One preg_match_all() to pick out the entire list of patterns in a single shot, then iterate over that result list and add only those to the $data array. I'll benchmark this technique against my files and see what I get. Alternatively, I could create an interface to manually add certain keys, something like:

Code:

$this->parser->loadKey(array('key1', 'key2', 'key3'));

This would be the most efficient obviously, but somewhat defeats the purpose of the automation.

[El Forum]

[eluser]Yoglets[/eluser]
Well, good news and bad news. It's faster and slower. If you have a large number of unused keys and a very small template, it's faster. But as soon as the template grows, even if the number of unused keys remains large, the cost of the one preg_match_all() call offsets all of the failed str_replace() calls. I'll try various combinations to see if maybe there's a somewhat predictable pattern, like only do the replacement if the template is less then 1K in size or something.